Re: [Resin-interest] Using Google id's with Resin
How are you getting the person's real name out of GAE's UserService? I don't see that. Maybe this is just something you get with Android auth? The short answer is to use OpenID (and OAuth to get permission on extra fields). But there is a problem with this - if you have a database full of google ids (not openids) there's no way to migrate. You can switch GAE to federated login and you'll get both the google id and openid, which will let you start populating your database when people log in, but to go full openid you'll have to do email matching with the accounts that haven't set their openid. Messy. Jeff On Sun, Sep 25, 2011 at 9:45 AM, Stargazer starga...@blueyonder.co.uk wrote: We have a Resin powered JEE app and are expanding it to work with Android. One of the cool things on Android is you know the user is logged into a Google account. With the Google App Engine, you can do more that just authenticate since they provide all the back end service data. For example, if I created a simple App Engine app which asked for the Google id and password, I could then say Hi John having pulled John as the real username, rather than the email address. So to expand we can either (gulp) lose Resin and move entirely to the App Engine, which I really don't want to do, or replicate the authentication system Google uses, as in the simple example above, to do it on Resin (which is what I prefer). In other words I want to authenticate a valid Google user using Resin but never see the password. I see this issue as becoming more and more common, for example Google just opened the API for Google+, and a great use case for us is to be able to access a users circles from server side java. So as usual its over to you smarts on this list for ideas, or suggestions such as if I should be looking at some OpenId or whatever based system I can roll in ;-) Sincere thanks... ___ 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 no longer deploys my war
Dunno, I create it with ant just like every other warfile I've ever made... but now that you mention it, when I examine the jar it appears to have two copies of every classfile. Didn't notice that before! And thus the mystery is solved. Wow, this one drove me nuts. At one point I was running this war on an Appengine backend, and the eclipse config for a GAE project puts the classes in WEB-INF/classes (but conveniently hides this in the package explorer). My ant buildfile compiles the classes to a 3rd directory, then includes both those classes and the contents of WEB-INF... you get the picture. Resin could use a better error message for this :-) I'm happy to be back on Resin though. Jeff On Wed, Jun 8, 2011 at 12:26 AM, Mattias Jiderhamn mj-li...@expertsystems.se wrote: Jeff, is it possible that there is something strange about the WAR file itself, like the compression...? May I ask how the WAR is created? Have you compared checksums between where it is created and where it is deployed so it isn't messed up in some transfer? /Mattias Jeff Schnitzer wrote (2011-06-07 02:49): ... FWIW, a simple stripped-down war file does deploy. So presumably it's something about my WARfile. But there's nothing about my WAR that is special - it deploys just fine on other containers. If I unjar it by hand, it deploys just fine on Resin. 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 no longer deploys my war
My war file doesn't use CDI (it's Guice-based), and doesn't have a
resin-web.xml or a beans.xml. It's just a vanilla webapp.
I replied with a copy of my (187k) log on startup but the message was
held for moderation by the mailing list software; not sure if it ever
went through. What looks to be the key error msg is this:
[11-06-07 00:03:43.401] {main}
WebAppController$206051672[production/webapp/default/ROOT] adding
archive to repository from
/Volumes/Slow/3rdparty/resin-pro-4.0.s110606/webapps/ROOT.war
[11-06-07 00:03:43.951] {main} java.lang.RuntimeException:
74688118b8dc9b133c3714aec4f7c7f843e69e90: file validation failed
because sha-1 hash '74688118b8dc9b133c3714aec4f7c7f843e69e90' does not
match expected '0ef77fbc7e5f514bf459fb8fe2dd772ccef2dc9b'
at
com.caucho.env.git.GitSystem.writeRawGitFile(GitSystem.java:600)
at
com.caucho.env.repository.FileRepository.writeRawGitFile(FileRepository.java:270)
at
com.caucho.env.repository.AbstractRepository.addArchive(AbstractRepository.java:744)
at
com.caucho.env.repository.AbstractRepository.addArchive(AbstractRepository.java:705)
at
com.caucho.env.repository.AbstractRepository.commitArchive(AbstractRepository.java:228)
at
com.caucho.env.deploy.ExpandDeployController.commitArchive(ExpandDeployController.java:472)
at
com.caucho.env.deploy.ExpandDeployController.extractApplication(ExpandDeployController.java:350)
at
com.caucho.env.deploy.ExpandDeployController.preConfigureInstance(ExpandDeployController.java:314)
at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:652)
at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:77)
at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:521)
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:658)
at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:77)
at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:521)
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:1228)
at
com.caucho.server.cluster.ServletService.start(ServletService.java:72)
at
com.caucho.env.service.ResinSystem.startServices(ResinSystem.java:513)
at
com.caucho.env.service.ResinSystem.start(ResinSystem.java:481)
at
com.caucho.server.resin.Resin.start(Resin.java:999)
at
com.caucho.server.resin.Resin.initMain(Resin.java:1127)
at
com.caucho.server.resin.Resin.main(Resin.java:1426)
Jeff
On Tue, Jun 7, 2011 at 4:25 PM, Keith Fetterman
kfetter...@go2marine.com wrote:
Hi Jeff,
I just had another thought that might be effecting your war file
deployment. Have you declaree any dependency injection / CanDI into
your resin.xml or resin-web.xml files? For example:
http://www.caucho.com/resin-4.0/examples/ioc-binding/index.xtp
When I upgraded our Web sites from resin 3.0.x to resin 4.x, I had a lot
of problems with this until I made changes to my Java classes. Resin
would fail silently, i.e., it never produced any errors even when
logging was set to the finest level. Resin would appear to start, but
nothing was loaded or deployed.
The culprit was declaring / using static method calls as my services and
beans.
Keith
On 06/06/2011 05:49 PM, Jeff Schnitzer wrote:
Seriously, I've done *nothing* special. I downloaded resin, unzipped
it, copied in my ROOT.war... and nothing. I've tried deleting the
ROOT/ directory. I've tried deleting the resin-data/ directory. I've
tried removing theweb-app id=/ root-directory=webapps/ROOT/
(what does that do, anyways?).
resin-admin shows a root webapp. not mine - just the default one it creates.
It just doesn't work.
FWIW, a simple stripped-down war file does deploy. So presumably it's
something about my WARfile. But there's nothing about my WAR that is
special - it deploys just
Re: [Resin-interest] Resin no longer deploys my war
I finally got around to trying this out, and no luck. I can't for the life of me figure out why Resin refuses to unpack my WAR. Every other appserver will, including an old copy of resin 4.0.9 I found lying around (unfortunately 4.0.9 has other issues). Jeff On Fri, Jun 3, 2011 at 9:57 AM, Jeff Schnitzer j...@infohazard.org wrote: Thanks - I will try this out. I gave up and switched to Tomcat. But I like it less than Resin, so maybe I will switch back. Jeff On Fri, Jun 3, 2011 at 9:43 AM, Keith Fetterman kfetter...@go2marine.com wrote: Hi Jeff, Are you still experiencing this problem? I experienced the same problem in resin 4.0.16 pro. I pulled my hair out including performing the steps you talked about in your email. I finally discovered that I had to turn versioning off. Here is a snippet from my resin.xml file: !-- creates the webapps directory for .war expansion -- !-- web-app-deploy path=webapps versioning=true/ -- web-app-deploy path=webapps/ The default resin.xml file has this set to true. I hope this helps Keith On 05/24/2011 02:23 PM, Jeff Schnitzer wrote: On Tue, May 24, 2011 at 2:04 PM, Scott Fergusonf...@caucho.com wrote: Also, what does the /resin-admin webapps tab say? It reports a webapp at /, but just the stock one. For example, if you've deployed a .war using the command-line deploy, that overrides the webapps/ directory. I haven't done anything... seriously, I just went through these steps: 1) Download resin-4.0.18.zip 2) Unzip it into a directory 3) Copy my ROOT.war into resin/webapps 4) Run resin No love. No error messages. I've also tried commenting outweb-app id=/ root-directory=webapps/ROOT/ but it makes no difference. I'm not quite sure what this line is supposed to do, though - shouldn't it be irrelevant if there is a ROOT.war file in webapps? Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- - Keith Fetterman Direct: 206-319-9434 Mariner Supply, Inc. 206-780-5670 http://www.go2marine.com kfetter...@go2marine.com http://www.boatersline.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] Resin no longer deploys my war
Thanks - I will try this out. I gave up and switched to Tomcat. But I like it less than Resin, so maybe I will switch back. Jeff On Fri, Jun 3, 2011 at 9:43 AM, Keith Fetterman kfetter...@go2marine.com wrote: Hi Jeff, Are you still experiencing this problem? I experienced the same problem in resin 4.0.16 pro. I pulled my hair out including performing the steps you talked about in your email. I finally discovered that I had to turn versioning off. Here is a snippet from my resin.xml file: !-- creates the webapps directory for .war expansion -- !-- web-app-deploy path=webapps versioning=true/ -- web-app-deploy path=webapps/ The default resin.xml file has this set to true. I hope this helps Keith On 05/24/2011 02:23 PM, Jeff Schnitzer wrote: On Tue, May 24, 2011 at 2:04 PM, Scott Fergusonf...@caucho.com wrote: Also, what does the /resin-admin webapps tab say? It reports a webapp at /, but just the stock one. For example, if you've deployed a .war using the command-line deploy, that overrides the webapps/ directory. I haven't done anything... seriously, I just went through these steps: 1) Download resin-4.0.18.zip 2) Unzip it into a directory 3) Copy my ROOT.war into resin/webapps 4) Run resin No love. No error messages. I've also tried commenting outweb-app id=/ root-directory=webapps/ROOT/ but it makes no difference. I'm not quite sure what this line is supposed to do, though - shouldn't it be irrelevant if there is a ROOT.war file in webapps? Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- - Keith Fetterman Direct: 206-319-9434 Mariner Supply, Inc. 206-780-5670 http://www.go2marine.com kfetter...@go2marine.com http://www.boatersline.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
[Resin-interest] Resin no longer deploys my war
I tried upgrading to 4.0.18 recently and deployment seems broken. Normally I copy my war file over webapps/ROOT.war, restart appserver, and it works. Now it seems the only way I can get a deployment working is by: 1) Deleting webapps/ROOT (the directory) 2) Manually un-jaring ROOT.war 3) Deleting the resin-data directory If I don't do #3, Resin recreates an old version of my app, not the new contents of ROOT.war. If I don't do #2, Resin creates an empty web project. This is really, insanely confusing :-( Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin no longer deploys my war
It does sound like that, but I'm running Resin as root. Jeff On Tue, May 24, 2011 at 1:56 AM, Mattias Jiderhamn mj-li...@expertsystems.se wrote: Sounds like a file permission issue, but you've checked that, haven't you...? /Mattias - Original Message - Subject: [Resin-interest] Resin no longer deploys my war Date: Tue, 24 May 2011 01:52:04 -0700 From: Jeff Schnitzer j...@infohazard.org I tried upgrading to 4.0.18 recently and deployment seems broken. Normally I copy my war file over webapps/ROOT.war, restart appserver, and it works. Now it seems the only way I can get a deployment working is by: 1) Deleting webapps/ROOT (the directory) 2) Manually un-jaring ROOT.war 3) Deleting the resin-data directory If I don't do #3, Resin recreates an old version of my app, not the new contents of ROOT.war. If I don't do #2, Resin creates an empty web project. This is really, insanely confusing :-( 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 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin no longer deploys my war
On Tue, May 24, 2011 at 8:11 AM, Paul Cowan co...@caucho.com wrote: Hi Jeff, We fixed a few bugs related to deployment in 4.0.17 and 4.0.18, perhaps the behavior you're expecting has changed. I tested by simply overwriting ROOT.war with a different ROOT.war and didn't have any issues. Resin will recreate the old app from resin-data directory, if you delete the war and directory, since it needs a ROOT webapp. So that behavior is expected. Some things to check are permissions (server-default user-name Resin is running as), resin:DeployService/ exists, webapp version is enabled (host-default web-app-deploy path=webapps versioning=true/). -Paul I don't know what to say... I'm running vanilla Resin 4.0.18 (non-pro), right out of the zipfile. I get the same behavior on both linux (started using the init.d script, running as root) and Mac (bin/resin.sh console, running as myself). The only changes I've made to resin.xml are tweaks to my logging configuration and disabling the resin-doc webapp. resin:DeployService and web-app-deploy are stock. I've tried commenting out the web-app id=/ root-directory=webapps/ROOT/ but it doesn't seem to make a difference one way or another. It almost seems like Resin just doesn't notice my ROOT.war, but there are no error messages and there's nothing wrong with the permissions. The file unjars just fine with the command line jar utility. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin no longer deploys my war
On Tue, May 24, 2011 at 2:04 PM, Scott Ferguson f...@caucho.com wrote: Also, what does the /resin-admin webapps tab say? It reports a webapp at /, but just the stock one. For example, if you've deployed a .war using the command-line deploy, that overrides the webapps/ directory. I haven't done anything... seriously, I just went through these steps: 1) Download resin-4.0.18.zip 2) Unzip it into a directory 3) Copy my ROOT.war into resin/webapps 4) Run resin No love. No error messages. I've also tried commenting out web-app id=/ root-directory=webapps/ROOT/ but it makes no difference. I'm not quite sure what this line is supposed to do, though - shouldn't it be irrelevant if there is a ROOT.war file in webapps? Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Classloader problems with hibernate validator and slf4j
So... now that the hibernate validator is part of the resin appserver classpath, there seems to be some sort of strange conflict with slf4j. java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory org.hibernate.validator.util.LoggerFactory.make(LoggerFactory.java:29) org.hibernate.validator.util.Version.clinit(Version.java:30) org.hibernate.validator.engine.ConfigurationImpl.clinit(ConfigurationImpl.java:52) org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:43) javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:269) javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111) org.subethamail.web.model.ErrorMapModel.clinit(ErrorMapModel.java:24) org.subethamail.web.action.CreateList.initialize(CreateList.java:79) org.tagonist.AbstractAction.execute(AbstractAction.java:50) org.tagonist.ActionTag.doEndTag(ActionTag.java:282) _jsp._list_0create_0submit__jsp._jspService(_list_0create_0submit__jsp.java:70) _jsp._list_0create_0submit__jsp._jspService(_list_0create_0submit__jsp.java:29) com.caucho.jsp.JavaPage.service(JavaPage.java:64) I can make the issue go away by copying slf4j-api and slf4j-jdk14 into resin/lib... but is there a better way to solve this? Admittedly I haven't tried removing hibernate-vaildator from my war yet. But that seems an odd solution. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Duplicate singletons
On Wed, Aug 11, 2010 at 1:08 PM, Scott Ferguson f...@caucho.com wrote: Jeff Schnitzer wrote: There seems to still be a problem with singletons exposed as hessian services. I can create a test project if necessary, but I'm seeing this behavior in two separate applications: 1) Create a @Singleton bean 2) Give the bean a @Startup @PostConstruct method that initializes some data 3) Give the bean a @HessianService annotation 4) Call the bean via hessian 5) Observe that the data isn't initialized Is this javax.ejb.Singleton or javax.inject.Singleton? (I still can't believe the JavaEE spec allows that confusion.) I'm using javax.inject.Singleton. FWIW javax.ejb.Singleton doesn't seem to register beans with the manager. I don't know if that's correct or not. I've filed it as http://bugs.caucho.com/view.php?id=4175 Cool. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Duplicate singletons
There seems to still be a problem with singletons exposed as hessian services. I can create a test project if necessary, but I'm seeing this behavior in two separate applications: 1) Create a @Singleton bean 2) Give the bean a @Startup @PostConstruct method that initializes some data 3) Give the bean a @HessianService annotation 4) Call the bean via hessian 5) Observe that the data isn't initialized This was a problem long ago in 4.0.0 (with the equivalent annotations at the time) but I thought it was fixed sometime later. I could be wrong about that though. The old workaround was to have the hessian endpoint on a different bean which itself injects the singleton. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
On Tue, Jul 20, 2010 at 12:21 PM, Scott Ferguson f...@caucho.com wrote:
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
Cool. If you get to a point where this is checked into Resin trunk,
I'd love to help you test it :-)
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
By the way, I was able to work past the lazy-init issue (presumably)
by using this block instead:
cfg:MessageBeanConfig
cfg:classtest.DeliveryListener/cfg:class
cfg:destination#{delivery}/cfg:destination
/cfg:MessageBeanConfig
However, enqueueing a message doesn't produce calls on my Listener.
It seems to produce some sort of spin-loop inside Resin.
Jeff
On Tue, Jul 20, 2010 at 1:17 PM, Jeff Schnitzer j...@infohazard.org wrote:
On Tue, Jul 20, 2010 at 12:21 PM, Scott Ferguson f...@caucho.com wrote:
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
Cool. If you get to a point where this is checked into Resin trunk,
I'd love to help you test it :-)
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
in
Object.wait() [11690b000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 107cf0860 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked 107cf0860 (a java.lang.ref.Reference$Lock)
main prio=5 tid=103000800 nid=0x100501000 in Object.wait() [10050]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 10809c708 (a com.caucho.boot.ResinBoot)
at com.caucho.boot.ResinBoot.main(ResinBoot.java:324)
- locked 10809c708 (a com.caucho.boot.ResinBoot)
VM Thread prio=9 tid=103089800 nid=0x116809000 runnable
Gang worker#0 (Parallel GC Threads) prio=9 tid=103002000
nid=0x102201000 runnable
Gang worker#1 (Parallel GC Threads) prio=9 tid=103002800
nid=0x102304000 runnable
Concurrent Mark-Sweep GC Thread prio=9 tid=103042000 nid=0x116511000 runnable
VM Periodic Task Thread prio=10 tid=103092800 nid=0x117293000
waiting on condition
Exception Catcher Thread prio=10 tid=103001800 nid=0x10171b000 runnable
JNI global references: 975
Heap
par new generation total 19136K, used 7024K [10681, 107cd, 107cd)
eden space 17024K, 28% used [10681, 106cdc108, 1078b)
from space 2112K, 100% used [1078b, 107ac, 107ac)
to space 2112K, 0% used [107ac, 107ac, 107cd)
concurrent mark-sweep generation total 63872K, used 2737K [107cd,
10bb3, 10e61)
concurrent-mark-sweep perm gen total 21248K, used 14067K [10e61,
10fad, 113a1)
On Tue, Jul 20, 2010 at 4:42 PM, Scott Ferguson f...@caucho.com wrote:
Jeff Schnitzer wrote:
By the way, I was able to work past the lazy-init issue (presumably)
by using this block instead:
cfg:MessageBeanConfig
cfg:classtest.DeliveryListener/cfg:class
cfg:destination#{delivery}/cfg:destination
/cfg:MessageBeanConfig
However, enqueueing a message doesn't produce calls on my Listener.
It seems to produce some sort of spin-loop inside Resin.
Try adding a ee:Startup/ or resin:Service/. Otherwise the bean will
never get instantiated. It shouldn't spin, though.
Although, this is a pretty twisted way of working around the issue :)
-- Scott
Jeff
On Tue, Jul 20, 2010 at 1:17 PM, Jeff Schnitzer j...@infohazard.org wrote:
On Tue, Jul 20, 2010 at 12:21 PM, Scott Ferguson f...@caucho.com wrote:
Thanks. It's a timing issue in CanDI. The jms:FileQueue was added to a
lazy-init which wasn't being evaluated when the #{delivery} was
processed. The fix will be in the next snapshot.
Cool. If you get to a point where this is checked into Resin trunk,
I'd love to help you test it :-)
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
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Message driven bean woes
It works! Just got this working against trunk:
jms:JmsConnectionFactory/
jms:MemoryQueue
ee:Nameddelivery/ee:Named
/jms:MemoryQueue
ejb-message-bean class=test.DeliveryListener
destination#{delivery}/destination
/ejb-message-bean
Without the jms:JmsConnectionFactory/ deployment will produce an
error something like:
'javax.jms.ConnectionFactory' with name 'null' is an unknown JMS resource.
Thanks,
Jeff
On Tue, Jul 20, 2010 at 6:13 PM, Scott Ferguson f...@caucho.com wrote:
Jeff Schnitzer wrote:
Neither ee:Startup/ nor resin:Service/ has any observable effect.
There's definitely some sort of cpu loop; as soon as I enqueue one
entry, one core goes to 99% for the java process. Occasionally the
thread hops between cores.
Thanks. The loop is unrelated to EJB or JMS.
The spin is related to changes in the sync/locking in the thread/alarm
code, moving to atomic locks where possible.
-- Scott
* It happens with both jms:FileQueue and jms:MemoryQueue.
* There seems to be a 1 or 2 second delay before the CPU pegs.
There's nothing obvious to me in the thread dump, but here it is...
2010-07-20 17:01:15
Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.3-b01-279 mixed mode):
resin-11 daemon prio=5 tid=101aca000 nid=0x1185fb000 waiting on
condition [1185fa000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283)
at
com.caucho.env.thread.ResinThread.waitForTask(ResinThread.java:199)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:157)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
resin-10 daemon prio=5 tid=101ac9000 nid=0x1184f8000 runnable [1184f7000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.readChunkLength(Hessian2StreamingInput.java:241)
at
com.caucho.hessian.io.Hessian2StreamingInput$StreamingInputStream.startPacket(Hessian2StreamingInput.java:167)
at
com.caucho.hessian.io.Hessian2StreamingInput.startPacket(Hessian2StreamingInput.java:94)
at com.caucho.hmtp.HmtpReader.readPacket(HmtpReader.java:102)
at com.caucho.hmtp.HmtpLink.run(HmtpLink.java:111)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
process reaper daemon prio=5 tid=101a89800 nid=0x1183f5000 runnable
[1183f4000]
java.lang.Thread.State: RUNNABLE
at java.lang.UNIXProcess.waitForProcessExit(Native Method)
at java.lang.UNIXProcess.access$900(UNIXProcess.java:17)
at java.lang.UNIXProcess$2$1.run(UNIXProcess.java:86)
watchdog- daemon prio=5 tid=10199c800 nid=0x1181a6000 in
Object.wait() [1181a5000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 106b74888 (a java.lang.UNIXProcess)
at java.lang.Object.wait(Object.java:485)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:115)
- locked 106b74888 (a java.lang.UNIXProcess)
at
com.caucho.boot.WatchdogChildProcess.run(WatchdogChildProcess.java:145)
at com.caucho.boot.WatchdogChildTask.run(WatchdogChildTask.java:174)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
watchdog-process-log-0-1 daemon prio=5 tid=10199c000 nid=0x1180a3000
runnable [1180a2000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:199)
at
java.lang.UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:227)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
- locked 106b76e48 (a java.io.BufferedInputStream)
at
com.caucho.boot.WatchdogChildProcess$WatchdogProcessLogThread.run(WatchdogChildProcess.java:745)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:169)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
resin-7 daemon prio=5 tid=10199b000 nid=0x117fa waiting on
condition [117f9f000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:283
[Resin-interest] svn?
I haven't been able to connect to the Resin svn server for a while... did something move? loa:Resin jeff$ svn up svn: Can't connect to host 'svn.caucho.com': Operation timed out loa:Resin jeff$ svn info Path: . URL: svn://svn.caucho.com/resin/trunk Repository Root: svn://svn.caucho.com Repository UUID: 9c94448d-38f1-0310-a231-d98308ff1ebf Revision: 7176 Node Kind: directory Schedule: normal Last Changed Author: alex Last Changed Rev: 7176 Last Changed Date: 2010-06-01 13:42:51 -0700 (Tue, 01 Jun 2010) Also, I wasn't able to find a document at the current caucho.com that explains how to read trunk. Obviously there once was one, since I managed to set it up a long time ago... Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Qualifier not working on 4.0.6
I'm making good progress getting SubEtha running on 4.0.6, but now I
seem to have a strange and self-contradictory error:
[10-05-30 11:24:11.854] {main}
org.subethamail.core.queue.InjectListener.outboundQueue:
javax.enterprise.inject.UnsatisfiedResolutionException: Can't find a
bean for
'java.util.concurrent.BlockingQueueorg.subethamail.core.queue.DeliveryQueueItem'
because no beans match the type and bindings
[...@org.subethamail.core.queue.deliveryqueue()].
Beans:
XmlBean[FileQueue,
{...@org.subethamail.core.queue.deliveryqueue(),
@javax.inject.Named(value=delivery), @Any()}, name=delivery,
@Singleton]
XmlBean[FileQueue,
{...@org.subethamail.core.queue.injectqueue(),
@javax.inject.Named(value=inject), @Any()}, name=inject, @Singleton]
There is clearly a FileQueue with @DeliveryQueue present, yet the
manager can't seem to resolve it!
Here's the resin-web.xml declaration of the FileQueue:
jms:FileQueue
queue:DeliveryQueue/
ee:Nameddelivery/ee:Named
/jms:FileQueue
Here's the injection point in InjectListener:
@Inject @DeliveryQueue BlockingQueueDeliveryQueueItem outboundQueue;
DeliveryQueue is pretty straightforward:
@Qualifier
@Target({FIELD,METHOD,PARAMETER})
@Retention(RUNTIME)
public @interface DeliveryQueue
{}
Any idea what might be wrong?
By the way, replacing our legacy plugin architecture (inherited from
JBoss4 days) with the @Any Instance? api produces amazingly clean
code! Really fantastic stuff.
Thanks,
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] NPE in EjbInjectionTarget
Trying to get SubEtha running on Resin 4.0.7, I'm getting a strange exception on startup: java.lang.NullPointerException at com.caucho.ejb.server.EjbInjectionTarget.newInstance(EjbInjectionTarget.java:273) at com.caucho.ejb.server.AbstractEjbBeanManager.newInstance(AbstractEjbBeanManager.java:535) at com.caucho.ejb.session.AbstractSessionContext.newInstance(AbstractSessionContext.java:103) at com.caucho.ejb.session.StatelessPool.allocate(StatelessPool.java:116) at org.subethamail.core.admin.AdminBean__StatelessProxy.establishPerson(AdminBean__StatelessProxy.java:438) at org.subethamail.core.admin.BootstrapperBean.bootstrapRoot(BootstrapperBean.java:141) at org.subethamail.core.admin.BootstrapperBean__ResinWebBean.bootstrapRoot(BootstrapperBean__ResinWebBean.java:90) at org.subethamail.core.admin.BootstrapperBean.bootstrap(BootstrapperBean.java:120) at org.subethamail.core.admin.BootstrapperBean__ResinWebBean.bootstrap(BootstrapperBean__ResinWebBean.java:67) at org.subethamail.core.admin.BootstrapperBean.start(BootstrapperBean.java:107) at org.subethamail.core.admin.BootstrapperBean__ResinWebBean.start(BootstrapperBean__ResinWebBean.java:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.caucho.config.j2ee.PostConstructProgram.inject(PostConstructProgram.java:119) at com.caucho.config.inject.CandiProducer.postConstruct(CandiProducer.java:239) at com.caucho.config.inject.InjectionTargetBuilder.postConstruct(InjectionTargetBuilder.java:205) at com.caucho.config.inject.ManagedBeanImpl.create(ManagedBeanImpl.java:155) at com.caucho.config.scope.AbstractScopeContext.get(AbstractScopeContext.java:97) at com.caucho.config.inject.InjectManager$ContextReferenceFactory.create(InjectManager.java:3825) at org.subethamail.core.admin.BootstrapperBean__ResinScopeProxy.__caucho_getDelegate(Unknown Source) at com.caucho.config.xml.XmlStandardPlugin.processAfterValidation(XmlStandardPlugin.java:222) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.caucho.config.inject.ExtensionManager$ExtensionObserver.notify(ExtensionManager.java:365) at com.caucho.config.inject.ObserverMap.fireEvent(ObserverMap.java:94) at com.caucho.config.inject.InjectManager.fireLocalEvent(InjectManager.java:2294) at com.caucho.config.inject.InjectManager.fireLocalEvent(InjectManager.java:2281) at com.caucho.config.inject.InjectManager.fireExtensionEvent(InjectManager.java:2267) at com.caucho.config.inject.InjectManager.bind(InjectManager.java:3026) at com.caucho.config.inject.InjectManager.environmentBind(InjectManager.java:3111) at com.caucho.loader.EnvironmentClassLoader.bind(EnvironmentClassLoader.java:786) at com.caucho.loader.EnvironmentClassLoader.start(EnvironmentClassLoader.java:803) at com.caucho.server.webapp.WebApp.start(WebApp.java:2987) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:712) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:575) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:160) at
[Resin-interest] Resin CanDI on GAE?
I'm retrofitting CDI into the part of my app that runs on Google Appengine (as opposed to the part that runs on Resin). I just saw Reza's comment on this blog entry: http://java.dzone.com/articles/weld-101-runs-gae What are the prospects for CanDI on GAE? Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
I doublechecked the spec and the current Resin behavior is the proper
behavior. I don't think this behavior has changed in the spec, so the
old behavior was a bug. You can't use the empty operator to test for
the existence of fields (or methods).
As to the rationale for the spec... it does make some amount of sense,
helping to reduce one very common type of bug (I'm getting properties
of a ThingA and the object turns out to be a ThingB). I'm sure all
the arguments for static typing vs duck typing apply here.
Note: There is nothing special about the empty operator; expressions
are resolved as normal and then the result is tested for null or empty
collection. If expression evaluation ever tries to access a field or
method that doesn't exist on an object, the EL resolver throws
PropertyNotFoundException or MethodNotFoundException.
Jeff
On Fri, May 7, 2010 at 2:47 PM, Aaron Freeman aaron.free...@layerz.com wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman aaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
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] Question about Resin 4.0.6
You might want to take a look at a project I created several years ago
that works pretty much like this. I still find it occasionally
useful, although most of my frontends are GWT and javascript these
days:
http://tagonist.tigris.org/
It lets you use JSP files as controllers but keeps your Java code nice
and tidy. Super-simple.
Jeff
On Fri, May 7, 2010 at 6:06 PM, Aaron Freeman aaron.free...@layerz.com wrote:
Yes, that's exactly right. In several instances we have many
controllers that are written in JSP (pure JSTL code), that c:import
our models (also in this case JSPs) and also c:import our views.
Works great!
The upside to it is: a) easier to code -- people with limited Java
expertise can modify the controllers if they are not too complex (and
rarely are), and b) you can change your controllers on the fly without
having to restart Resin (primary reason we do this).
Aaron
On 5/7/2010 5:05 PM, Rachel McConnell wrote:
This comment isn't helpful I know but I am very curious about this.
The code you quoted is a tag library call using the EL. How is that
not part of the UI? Are you writing controllers in JSP somehow?
Rachel
On Fri, May 7, 2010 at 2:47 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
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] Sending log4j logs to the web apps log folder
Why would you want Resin to log through slf4j? I actually think this
would make a really big mess out of our apps, because now the slf4j
jars would be provided for us and potentially cause conflicts.
Resin provides a concrete logging system (in this case, j.u.l). We
write our code using slf4j and by using the slf4j-jdk14.jar adapter,
everything just works. This seems pretty straightforward. I'd hate
to have to configure the slf4j logging in the container.
Jeff
On Fri, Apr 2, 2010 at 1:13 PM, Chris Pratt thechrispr...@gmail.com wrote:
Consider this another vote for a possible switch to using SLF4j as the Resin
logging interface. It's a very thin API that is an extremely powerful
aggregator of log information.
(*Chris*)
On Fri, Apr 2, 2010 at 12:57 PM, Jeff Schnitzer j...@infohazard.org wrote:
I'm pretty sure that it's possible to configure any possible
combination of input loggers and output destinations by mixing and
matching the various components of SLF4J.
To get log4j output to java.util.logging, you could use the
log4j-slf4j bridge, then use the slf4j output module that dumps to
java.util.logging. There's no configuration, you just pick which jar
files you include in your project. In this case it would be:
slf4j-X.X.X.jar (the base jar)
log4j-over-slf4j-X.X.X.jar (the bridge)
slf4j-jdk14-X.X.X.jar (the output module)
Just add these jars to your project (leave out the log4j jar) and I'm
pretty sure that you'll find all log4j output sent to the resin
logger.
Jeff
On Fri, Apr 2, 2010 at 12:43 PM, Scott Ferguson f...@caucho.com wrote:
Jon Stevens wrote:
I use this class to do JDK- commons-logging (which could either be
modified to go directly to log4j or, just through CL and then to
log4j)...
I think he needs the other way around, from log4j to java.util.logging
(?)
By the way, in Resin 4.0.6 you'll be able to do the same thing with
resin xmlns=...
system
logger name= level=
mypkg:JDKLogHandler xmlns=urn:java:org.mycom.mypkg
levelall/level
/mypkg:JDKLogHandler
/logger
/system
I'm not sure setting the Logger level to all would be a good idea,
though, because Logger.isLoggable() would always return true, which
would harm performance somewhat.
(The system is just to ensure it's configured in the system
classloader context, since resin is a child of the system loader. And
at some point I need to look into providing an adapter to log4j handlers
so you can configure log4j handlers as a java.util.logging handler
directly in Resin.)
-- Scott
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.logging.Handler;
import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.LogRecord;
import java.util.logging.Logger;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Writes JDK log messages to commons logging.
*
* @see http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging;
*/
public class JavaLoggingToCommonLoggingRedirector
{
static JDKLogHandler activeHandler;
/**
* Activates this feature.
*/
public static void activate()
{
try
{
Logger rootLogger = LogManager.getLogManager().getLogger();
// remove old handlers
for (Handler handler : rootLogger.getHandlers())
{
rootLogger.removeHandler(handler);
}
// add our own
activeHandler = new JDKLogHandler();
activeHandler.setLevel(Level.ALL);
rootLogger.addHandler(activeHandler);
rootLogger.setLevel(Level.ALL);
// done, let's check it right away!!!
Logger.getLogger(JavaLoggingToCommonLoggingRedirector.class.getName()).info(
activated: sending JDK log messages to Commons Logging);
}
catch (Exception exc)
{
LogFactory.getLog(JavaLoggingToCommonLoggingRedirector.class).error(activation
failed, exc);
}
}
public static void deactivate()
{
Logger rootLogger = LogManager.getLogManager().getLogger();
rootLogger.removeHandler(activeHandler);
Logger.getLogger(JavaLoggingToCommonLoggingRedirector.class.getName()).info(dactivated);
}
protected static class JDKLogHandler extends Handler
{
private MapString, Log cachedLogs = new ConcurrentHashMapString,
Log();
private Log getLog(String logName)
{
Log log = this.cachedLogs.get(logName);
if (log == null)
{
log = LogFactory.getLog(logName);
this.cachedLogs.put(logName, log);
}
return log;
}
@Override
public void publish(LogRecord record)
{
Log log = this.getLog(record.getLoggerName());
String message = record.getMessage();
Throwable exception = record.getThrown();
Level level = record.getLevel();
if (level == Level.SEVERE)
{
log.error(message, exception);
}
else if (level == Level.WARNING)
{
log.warn(message, exception);
}
else if (level == Level.INFO)
{
log.info http://log.info(message, exception);
}
else if (level
Re: [Resin-interest] 4.0.0 on osx deploy problem
FWIW, Resin on OSX seems to work fine despite the error messages. Jeff On Sat, Mar 20, 2010 at 6:12 AM, Jon Stevens latch...@gmail.com wrote: Yes, I can't remember what the solution was. =( Sorry! jon On Sat, Mar 20, 2010 at 2:16 AM, Rick Mann rm...@latencyzero.com wrote: John, did you ever find an answer to this? I'm getting it, too. On Jun 29, 2009, at 22:50:52, Jon Stevens wrote: Here is another problem. When deploying subetha on osx using the apple jdk 6, I get the stack trace below. When deplying subetha on osx using the landon fuller soylatte jdk, things work fine. I get a different set of errors using jdk5 which relate to the resin servlets apparently being compiled with jdk6. [16][ ~/checkout/resin-4.0.0 ]% ./bin/resin.sh Intentionally suppressing recursive invocation exception! java.lang.IllegalStateException: recursive invocation at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1394) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1377) at sun.security.jca.ProviderConfig$1.run(ProviderConfig.java:64) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.getLock(ProviderConfig.java:62) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) at sun.security.jca.ProviderList.getProvider(ProviderList.java:215) at sun.security.jca.ProviderList.getService(ProviderList.java:313) at sun.security.jca.GetInstance.getInstance(GetInstance.java:140) at java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148) at sun.security.pkcs.PKCS7.parseSignedData(PKCS7.java:244) at sun.security.pkcs.PKCS7.parse(PKCS7.java:141) at sun.security.pkcs.PKCS7.parse(PKCS7.java:110) at sun.security.pkcs.PKCS7.init(PKCS7.java:92) at sun.security.util.SignatureFileVerifier.init(SignatureFileVerifier.java:80) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:256) at java.util.jar.JarVerifier.update(JarVerifier.java:188) at java.util.jar.JarFile.initializeVerifier(JarFile.java:321) at java.util.jar.JarFile.getInputStream(JarFile.java:386) at sun.misc.JarIndex.getJarIndex(JarIndex.java:99) at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:606) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:597) at sun.misc.URLClassPath$JarLoader.init(URLClassPath.java:581) at sun.misc.URLClassPath$3.run(URLClassPath.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:320) at sun.misc.URLClassPath.getLoader(URLClassPath.java:297) at sun.misc.URLClassPath.getResource(URLClassPath.java:167) at java.net.URLClassLoader$1.run(URLClassLoader.java:192) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at sun.misc.Launcher$ExtClassLoader.findClass(Launcher.java:244) at java.lang.ClassLoader.loadClass(ClassLoader.java:319) at java.lang.ClassLoader.loadClass(ClassLoader.java:309) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330) at java.lang.ClassLoader.loadClass(ClassLoader.java:254) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:402) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at java.lang.SystemClassLoaderAction.run(ClassLoader.java:2150) at java.security.AccessController.doPrivileged(Native Method) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1407) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1377) Intentionally suppressing recursive invocation exception! java.lang.IllegalStateException: recursive invocation at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1394) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1377) at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:231) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:225) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:205) at sun.security.jca.ProviderList.getProvider(ProviderList.java:215) at sun.security.jca.ProviderList.getService(ProviderList.java:313) at sun.security.jca.GetInstance.getInstance(GetInstance.java:140) at java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:148) at sun.security.pkcs.PKCS7.parseSignedData(PKCS7.java:244) at sun.security.pkcs.PKCS7.parse(PKCS7.java:141)
Re: [Resin-interest] HempMemoryQueue Exception when synchronizing sessions between two nodes in a cluster
I know that Jon has spent many, many days debugging and tuning JBoss Cache on a production cluster, so I'd endorse his review, despite the brashness. Jeff On Thu, Dec 17, 2009 at 3:37 PM, Jon Stevens latch...@gmail.com wrote: DO NOT USE JBOSS CACHE. Pile of shit. ehcache + terracotta (yes, there is an oss free version) = love. I'm not super clear on what you want, but it sounds like you want the TIM-MasterWorker (ExecutorService): http://forge.terracotta.org/releases/projects/tim-messaging/docs/about.html jon On Thu, Dec 17, 2009 at 11:51 AM, Wesley Wu wumen...@gmail.com wrote: So if I want my beans synchronized across the cluster, I have to use either JMS or some thirdparty cluster middleware like JBossCache? -Wesley ___ 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 mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] support spatial queries in amber
It's worth mentioning that Hibernate works great as a JPA provider for
Resin. I haven't tried it, but there's this:
http://www.hibernatespatial.org/
Jeff
On Wed, Dec 16, 2009 at 9:25 AM, Scott Ferguson f...@caucho.com wrote:
Riccardo Cohen wrote:
I really would like to know what is the Caucho point of view about this...
At the moment, Amber development is being put on hold (except critical
bugs), until we finish the web profile, because our main strategy is to
focus on the core quality for both Resin and Quercus.
So we would not be looking at adding spatial support for another 6
months at minimum, and even then we may decide Amber is still a lower
priority than core Resin quality.
-- Scott
Thanks
Riccardo Cohen wrote:
Hello
I use mysql with spatial index and would like to use amber queries with
spatial field
I tried these sort of queries :
select p from Prop p where
Spatial.within(p.pos,Spatial.mPointFromText('MULTIPOINT(238500
6229301,238500 6260453,283700 6260453,283700 6229301)',0))
But the java program stops (with no exception) when I call createQuery()...
I found nothing in amber doc, but I've read here :
http://www.jpox.org/docs/1_2/spatial.html
that there could be spatial support in jpql.
Is there any plan to add spatial support in amber ?
Thanks
___
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] packaging EB3 application with Resin
As a longtime J2EE developer, let me suggest that life is far more pleasant if you abandon the atrocious EAR packaging morass and build your applications in one or more WARs. Just put all your classes in WEB-INF/classes (ejbs, servlets, etc), make sure you have WEB-INF/classes/META-INF/beans.xml and WEB-INF/classes/META-INF/ejb-jar.xml, and it all works the way you would expect. Note that separate WARs will be in separate classloader scopes, so inter-WAR calls will be Hessian not local method calls. But this makes life a lot easier when you want to relocate a WAR to a different server. Jeff On Mon, Nov 16, 2009 at 10:02 AM, Vincent LAUGIER vincent.laug...@helmet.fr wrote: Hello Alex, then we are waiting for the resin 4 stable release (we need to stick to resin 3 for the moment because of problem with the persistence context injection, see http://forum.caucho.com/showthread.php?t=1927). Resin supports the ear layout as well as defining ejbs in resin-web.xml What do you mean by defining ejbs in resin-web.xml ? Could this be a workaround to package the project in differents WARs (one WAR for the entity beans, another for the session beans...) ? regards Vincent This is only available in Resin 4. I don't believe there is a separate example, however there is a detailed draft of spec published on the blog: http://blog.caucho.com/?p=225 ___ 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 mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Controlling pool size for stateless EJBs
Thanks. Now that any bean can be given @TransactionAttribute and injection, the only point to using @Stateless seems to be pooling. Jeff On Tue, Nov 3, 2009 at 9:59 AM, Scott Ferguson f...@caucho.com wrote: Jeff Schnitzer wrote: Is it possible to control the pool size for stateless EJBs? I think I'm looking for something equivalent to ejb-message-bean message-consumer-max=2 but for ejb-session-bean. The docs say that session beans are pooled, but I don't see anything about how to configure this pool. The use case is that I have a rather expensive resource (held-open connections to Apple's crappy iPhone Push Notification Service) that requires pooled access. The stateless pool is infinite in size. Or rather, the idle-pool size is 1, and the active pool size is infinite. There's no throttling of the active size. I'm not sure if this is a capability we want to add, but I've created a bug report at http://bugs.caucho.com/view.php?id=3739. Since session EJBs were really designed to be lightweight custom XA resources, like a cheap JDBC driver, it may make sense. -- Scott 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 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Controlling pool size for stateless EJBs
Is it possible to control the pool size for stateless EJBs? I think I'm looking for something equivalent to ejb-message-bean message-consumer-max=2 but for ejb-session-bean. The docs say that session beans are pooled, but I don't see anything about how to configure this pool. The use case is that I have a rather expensive resource (held-open connections to Apple's crappy iPhone Push Notification Service) that requires pooled access. Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Tabulation evil
This is really just a point of curiosity... What editor are you guys using at Caucho? I've noticed all the code is formatted using a bizarre combination of tabs and spaces, like this: 1 indent = 4 spaces 2 indents = 1 tab 3 indents = 1 tab + 4 spaces 4 indents = 2 tabs 5 indents = 2 tabs + 4 spaces ...which, setting aside longstanding religious wars about tabs vs spaces, seems to combine the worst characteristics of each approach. I'm not really complaining, since Eclipse will fix it for me with two mouse clicks, but I'm terribly curious to know what editor can even be configured to abuse code like that :-) Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[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
Re: [Resin-interest] 4.0.2 schedule
Thanks for the update. Would it be helpful if we filed bugs against trunk? I tried it out a week ago but pretty quickly ran into a problem (@Named @RequestScoped didn't show up in the request attrs). I figured you guys were still working on it and probably didn't need the distraction, but if it would be useful, we can start reporting issues. Thanks, Jeff On Monday, October 12, 2009, Scott Ferguson f...@caucho.com wrote: FYI, we're taking extra time on 4.0.2 to bring it up from a development release to a stable release. That process is taking several weeks of extra work. Our current target is the end of October, but that may slip if 4.0.2 is not ready by then. -- 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
[Resin-interest] Building from trunk
I just tried ant dist from trunk and got an UNRESOLVED DEPENDENCIES error from Ivy: [ivy:retrieve] :: problems summary :: [ivy:retrieve] WARNINGS [ivy:retrieve] io problem while parsing ivy file: http://repository.jboss.com/maven2/jboss/jboss-common/2.2.1/jboss-common-2.2.1.pom: Impossible to load parent for file:/Users/jeff/.ivy2/cache/jboss/jboss-common/ivy-2.2.1.xml.original. Parent=org.jboss#jboss-parent;3 [ivy:retrieve] io problem while parsing ivy file: http://repository.jboss.com/maven2/jboss/jboss-common-core/2.2.0.GA/jboss-common-core-2.2.0.GA.pom: Impossible to load parent for file:/Users/jeff/.ivy2/cache/jboss/jboss-common-core/ivy-2.2.0.GA.xml.original. Parent=jboss#jboss-common;2.2.1 [ivy:retrieve] module not found: jboss#jboss-common-core;2.2.0.GA [ivy:retrieve] jboss: tried [ivy:retrieve] http://repository.jboss.com/maven2/jboss/jboss-common/2.2.1/jboss-common-2.2.1.pom [ivy:retrieve] :: [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: [ivy:retrieve] :: [ivy:retrieve] :: jboss#jboss-common-core;2.2.0.GA: not found [ivy:retrieve] :: [ivy:retrieve] [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS Am I doing something wrong? This is the first Ivy-based project I've tried to build. Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Building from trunk
I discovered the target ant resin.dist.build which seems to get farther, but then fails to find resin-cxf.jar: BUILD FAILED /Users/Shared/3rdparty/Resin/build-common.xml:753: The following error occurred while executing this line: /Users/Shared/3rdparty/Resin/build-common.xml:569: The following error occurred while executing this line: /Users/Shared/3rdparty/Resin/build-common.xml:433: Warning: Could not find file /Users/Shared/3rdparty/Resin/artifacts/cxf/dist/resin-cxf.jar to copy. So I tried ant artifacts, which did produce the resin-cxf.jar, but then failed to compile the mule classes because org.mule doesn't exist. And while the resin.dist.build gets a little farther, it needs more unbuilt artifacts. I scoured the wiki, the mailing list, and the source tree for some sort of description on how to build but for now, it seems I'm code 1 jeff 0 :-/ Jeff On Fri, Sep 25, 2009 at 8:18 PM, Jeff Schnitzer j...@infohazard.org wrote: I just tried ant dist from trunk and got an UNRESOLVED DEPENDENCIES error from Ivy: [ivy:retrieve] :: problems summary :: [ivy:retrieve] WARNINGS [ivy:retrieve] io problem while parsing ivy file: http://repository.jboss.com/maven2/jboss/jboss-common/2.2.1/jboss-common-2.2.1.pom: Impossible to load parent for file:/Users/jeff/.ivy2/cache/jboss/jboss-common/ivy-2.2.1.xml.original. Parent=org.jboss#jboss-parent;3 [ivy:retrieve] io problem while parsing ivy file: http://repository.jboss.com/maven2/jboss/jboss-common-core/2.2.0.GA/jboss-common-core-2.2.0.GA.pom: Impossible to load parent for file:/Users/jeff/.ivy2/cache/jboss/jboss-common-core/ivy-2.2.0.GA.xml.original. Parent=jboss#jboss-common;2.2.1 [ivy:retrieve] module not found: jboss#jboss-common-core;2.2.0.GA [ivy:retrieve] jboss: tried [ivy:retrieve] http://repository.jboss.com/maven2/jboss/jboss-common/2.2.1/jboss-common-2.2.1.pom [ivy:retrieve] :: [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: [ivy:retrieve] :: [ivy:retrieve] :: jboss#jboss-common-core;2.2.0.GA: not found [ivy:retrieve] :: [ivy:retrieve] [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS Am I doing something wrong? This is the first Ivy-based project I've tried to build. Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] character encoding
I wrote up a quick blurb on the issues surrounding character encoding on the Resteasy list recently: http://sourceforge.net/mailarchive/message.php?msg_name=540eb7210908281001r6aafaa55u78615debb704e4c1%40mail.gmail.com The short of it is that, if you can get away with it, you should set UTF-8 everywhere. In particular, you should set the platform default with -Dfile.encoding=utf-8 and ensure that all your pages are rendered in utf-8 (ie with the JSP directive). It's cool that Resin has a config parameter for this, but it will be obviated by setting the platform default - right, Scott? The main problem is that POSTed form data will be sent by the browser in whatever charset encoding was used on the host page, and this information is not sent along with the request. So the server must guess... and that usually means going with the platform default. If you for some reason need to manage multiple charsets in the same application, you'll need a Filter that executes early and calls request.setCharacterEncoding() *before* any code calls request.getParameter(). Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Noob question: Do I have to restart?
Hot deployment works fine for me out of the box, but note that Resin doesn't immediately reload the webapp when web.xml or the war changes. You have to actually request a page, then the app will reload. If you change JSP files they are picked up immediately, no reload necessary. Jeff On Tue, Sep 22, 2009 at 7:23 AM, Rom Sok romsok.re...@gmail.com wrote: Hi, Sorry about the newbie question, do I have to restart Resin every time I drop a new version of some file into the deployment directory? like say web.xml? Is there a way to just reload the app without doing the whole Stop - Quit - httpd.exe all over again? Also, is that what is called hot deployment? Or is there another term for redeploying an app without starting the server? Thanks, ___ 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] Cookie security over SSL (https) connections
Why aren't you creating the cookies with setSecure(true) in the first place?
If you have tons of legacy code that sets cookies, why not create a
Filter that wraps HttpServletResponse (there is a convenient
HttpServletResponseWrapper for this), intercepts the addCookie()
method calls, and calls setSecure(true)?
If you want this value set, you need to set it outbound, not after
they've already been to the browser.
Jeff
On Wed, Sep 9, 2009 at 3:44 AM, Abhinav Guptaabhi...@appirio.com wrote:
Hi All,
This problem is regarding cookie security over SSL(https). We are running a
J2EE webapplication, our motive is to get the cookie's isSecure flag set
to true. We tried researching around the resin config settings for this but
no luck. Details of the approach we tried and the issue faced are elaborated
below.
Enviornment Details
1. Resin 3.1.7 server running a webapplication called tool
2. Apache is in the front forwarding/redirecting all inbound traffic to the
resin server.
3. Apache is setup with trusted SSL certificates from godaddy.
Problem Details
By default for all secure https requests, resin is sending cookies back with
isSecure flag as false.
We tried looking for resin config settings to fix this, but can't find any
setting. So we created a Servlet filter in our webapp
to trap all inbound requests and manually set the isSecure flag to true.
This servlet filter approach partially fixed the problem. We are saying
partially because there are two cookies created by
the application in browser.
Cookie 1: Its path is domain name/ and the isSecure flag is false
Cookie 2: Its path is domain name/tools and the isSecure flag is true
So Cookie 2 is as expected, but Cookie 1 is not coming secured, to fix this
we tried deploying the same servlet filter in the ROOT webapp of resin. But
the problem persisted as before.
Here is the servlet filter code.
public class CookieFilter implements Filter {
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) throws ServletException, IOException {
// Secure if its a Http based request
if (req instanceof HttpServletRequest) {
HttpServletRequest httpReq = (HttpServletRequest) req;
HttpServletResponse httpRes = (HttpServletResponse) res;
Cookie[] cookies = httpReq.getCookies();
if (cookies != null cookies.length 0) {
for (Cookie cookie : cookies) {
// Make the cookie secure
cookie.setSecure(true);
// Add it to the response
httpRes.addCookie(cookie);
}
}
}
chain.doFilter(req, res);
}
public void init(FilterConfig arg0) throws ServletException {
}
public void destroy() {
}
}
Please suggest.
Regards,
Abhinav
___
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] Class load order in a WAR
On Mon, Aug 24, 2009 at 12:17 PM, Scott Fergusonf...@caucho.com wrote: The WEB-INF/classes should work. You could also modify the class- loader in app-default.xml (although that's generally not recommended.) Oops, heh. Apparently I had overlooked my own debug message; it was working. Thanks. Very cool. Although, the main annotations are changing because of JSR-330. This spec is pretty rough on early adopters. I saw that in the svn history, no worries. @Default and @Qualifier make more sense to me than @Current and @BindingType anyways. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0.1 doesn't like Hibernate
Resin 4.0.1 doesn't seem to work with Hibernate anymore. When
Hibernate is configured as the JPA provider, attempts to inject an
EntityManager produce this:
[09-08-04 15:54:16.283] {http--8080-5} FINES [InjectManage]
InjectManager[]
bind(EntityManager,[...@javax.enterprise.inject.current()]) - none
[09-08-04 15:54:16.285] {http--8080-5} WARNI [ErrorPageMan]
test.EchoService.em:
javax.enterprise.inject.UnsatisfiedResolutionException: Can't find a
bean for 'interface javax.persistence.EntityManager' because no beans
implementing that class have been registered with the injection
Manager.
However there are no error messages on startup; it appears that
Hibernate initializes normally.
There is a test case here:
http://code.google.com/p/scratchmonkey/source/browse/#svn/resin4/resource_injection
If you comment out
providerorg.hibernate.ejb.HibernatePersistence/provider in
persistence.xml, the injection works. If you leave it, you can't
inject. If you use @PersistenceContext instead of @Current, it
complains that the persistence unit cannot be found.
Any ideas or workarounds?
Thanks,
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] @Named doesn't work in 4.0.1
Another bug report: It appears that @Named isn't working in 4.0.1. When I create an @ApplicationScoped @Named(foo) object, it doesn't seem to be available in EL. This is also demonstrated by the index.jsp of the sample app: http://code.google.com/p/scratchmonkey/source/browse/#svn/resin4/resource_injection Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] SubEtha mailing list server now released on Resin
We have just released v2 of the opensource SubEtha mailing list server, rearchitected to use Resin and CanDI. We are very, very happy with the new design that CanDI enables. Here it is: http://www.subethamail.org/ Thanks Scott, Steve, Emil, and the rest of the Caucho team (and great meeting you last night at JavaOne)! If you're interested in converting your mailing lists to SubEtha, we'd be happy to help :-) Thanks, Jeff, Scott, and Jon ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Can user threads call ejb methods?
Is there a problem calling ejb methods from user-started threads inside the resin container? Yes, I know the ejb spec says that applications shouldn't start threads, but part of the spec is lame. The SubEtha mailing list server relies on an SMTP processing library which starts its own threads and then makes callbacks into our handlers as the email arrives. These handlers call into an ejb which processes the message in a transaction. We're seeing some really bizarre behavior where sometimes there is a transaction and sometimes there isn't. Could this be because the call is being done on a non-resin-started thread? If so, is there any workaround? Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Can user threads call ejb methods?
Nevermind, the problem was something else. Calling a find() method on an EntityManager outside of a transaction scope, then calling an EJB which has a transaction scope causes all manner of havoc when the EJB tries to write to the database. Jeff On Tue, Jun 2, 2009 at 5:33 PM, Jeff Schnitzer j...@infohazard.org wrote: Is there a problem calling ejb methods from user-started threads inside the resin container? Yes, I know the ejb spec says that applications shouldn't start threads, but part of the spec is lame. The SubEtha mailing list server relies on an SMTP processing library which starts its own threads and then makes callbacks into our handlers as the email arrives. These handlers call into an ejb which processes the message in a transaction. We're seeing some really bizarre behavior where sometimes there is a transaction and sometimes there isn't. Could this be because the call is being done on a non-resin-started thread? If so, is there any workaround? Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Hessian Remote Refs
H... let me ask the question that ScottH is, I think, trying to ask: What is the best way to make multiple hessian calls within a single session? Ie, calls to a @SessionScoped object will get the same instance. Jeff On Fri, May 15, 2009 at 2:06 PM, Scott Ferguson f...@caucho.com wrote: On May 15, 2009, at 1:21 PM, Scott Hernandez wrote: I have setup a hessian service (servlet) and when returning objects (stateless ejb for example) I see that a SingletonHandle instance if returned over the protocol. The client proxy then unpacks the object and tries to call the local (client) Injector to get the instance, instead of making the remote call to retrieve the instance from the server. How can I have the Hessian protocol return a ref to my actual bean, or a remote reference it won't try to resolve (create) at the client? The issue is on the EJB end, not technically Hessian. You might be able to create a writeReplace() method (part of the java.io.Serializable pattern), to save a stub that will then deserialize into a Hessian client proxy. -- Scott Here is the type of code I'm using on the client: HessianProxyFactory fact = new HessianProxyFactory(); fact.setOverloadEnabled(true); fact.setUser(god); fact.setPassword(loves us all); MyService myService = (MyService)fact.create(MyService.class, http://localhost:8080/mywebapp/api/myservice;); myService.doServerThing(); // does server thing OtherBean ob = myServer.getOtherBean(); //UnsatisfiedDependencyException ; this should be called on the server ob.changeServerState(); OtherAppScopeBean oasb = myServer.getOtherAppScopeBean(); String[] sArr = oasb.doSomething(); Thanks in advance, 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 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Hessian remoted objects with @ApplicationScoped break
ScottH and I have spent some time (fortunately, well-spent time in a pub with wifi and a deep reserve of Magners) trying to figure out why one of our @ApplicationScoped objects seems to have several instances in the container. The problem seems to be when you declare the servlet-mapping in resin-web.xml. We have a test with two beans, EchoService (@Stateless) and DeeperService (@ApplicationScoped). EchoService calls DeeperService, which logs the object id. When DeeperService has no servlet-mapping, calls to EchoService always return the same DeeperService id. When DeeperService also has a servlet-mapping, calls to EchoService return different DeeperService ids. Code to demonstrate this is here: http://scratchmonkey.googlecode.com/svn/resin4/hessian_scopes This is a bug, right? Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Custom hessian serialization in Resin
Is there a way to register custom hessian serializers in Resin? Resin4 can't serialize java.net.URL :-( Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Custom hessian serialization in Resin
Solved the problem of serializing a byte[]... it had nothing to do
with the byte[], it was because we are calling overloaded methods.
Must call HessianProxyFactory.setOverloadEnabled(true), which we here
are now calling the setBroken(false) method :-)
Still can't deserialize java.net.URL, looks like Hessian is calling
the URL(String) constructor and passing in a null.
Jeff
On Thu, May 14, 2009 at 11:27 AM, Jeff Schnitzer j...@infohazard.org wrote:
In addition, we're having problems serializing a byte[].
One additional complication is that if we turn com.caucho.hessian
logging to finest, it throws an exception that is not thrown when
logging is lower (and not useful, unfortunately):
[11:21:06.493] {http--8080-9} WARNING [ErrorPageManager]
java.lang.IllegalStateException: 1 is an unknown object type
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState$ObjectState.init(HessianDebugState.java:1345)
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState$State.nextObject(HessianDebugState.java:523)
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState$CompactListState.next(HessianDebugState.java:1651)
[11:21:06.493] {http--8080-9} at
com.caucho.hessian.io.HessianDebugState.next(HessianDebugState.java:98)
Thanks,
Jeff
On Thu, May 14, 2009 at 11:05 AM, Jeff Schnitzer j...@infohazard.org wrote:
Is there a way to register custom hessian serializers in Resin?
Resin4 can't serialize java.net.URL :-(
Thanks,
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Authentication using hessian
We have basic authentication and access control with Hessian working.
Auth in Hessian is done with BASIC auth, therefore there must be a
BasicLogin - our custom Login must extend that class.
The configuration of this is, unfortunately, tricky to figure out.
Our custom Login is picked up out of the classpath, so if you declare
it (or anything else) in resin-web.xml the appserver will throw
ambiguity errors.
There still seem to be a lot of problems - for instance, the IfRole,
IfNetwork etc stuff described in the documentation doesn't exist.
But that isn't holding us up.
Our blocking problem now is that there doesn't seem to be any way to
get the caller Principal in an EJB. Injection of the SessionContext
doesn't work:
@Resource SessionContext ctx; (standard ejb3 approach)
@Current SessionContext ctx; (expected CanDI approach)
both fail. ScottH found a workaround, calling
SecurityContext.getUserPrincipal(), but this only works in the webapp
and doesn't work from a Hessian call.
We have the opensource SubEtha mailing list server deployed on Resin4,
and it seems to work, but we can't run the unit tests without hessian.
Obviously we can't release the server without running unit tests :-(
Any ideas?
Thanks,
Jeff
On Fri, May 8, 2009 at 8:03 PM, Jeff Schnitzer j...@infohazard.org wrote:
Hessian auth doesn't seem to work. I have a small test project here:
http://scratchmonkey.googlecode.com/svn/resin4/programmatic_auth
The client code is very simple:
public static void main(String[] args) throws Exception
{
HessianProxyFactory fact = new HessianProxyFactory();
fact.setUser(harry);
fact.setPassword(potter);
String url = http://localhost:8080/ct/api/Echo;;
Echo ech = (Echo)fact.create(Echo.class, url);
ech.echo(greetings, program);
}
Yet even with a simple XmlAuthenticator on the backend, it always
gives me permission denied. I've tried putting my own authenticator
on the backend and it never seems to get called.
Is this a bug or am I doing something wrong? Has anyone successfully
performed remote authentication using hessian?
This is using the 4.0.0 release.
Thanks,
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Authentication using hessian
Hessian auth doesn't seem to work. I have a small test project here:
http://scratchmonkey.googlecode.com/svn/resin4/programmatic_auth
The client code is very simple:
public static void main(String[] args) throws Exception
{
HessianProxyFactory fact = new HessianProxyFactory();
fact.setUser(harry);
fact.setPassword(potter);
String url = http://localhost:8080/ct/api/Echo;;
Echo ech = (Echo)fact.create(Echo.class, url);
ech.echo(greetings, program);
}
Yet even with a simple XmlAuthenticator on the backend, it always
gives me permission denied. I've tried putting my own authenticator
on the backend and it never seems to get called.
Is this a bug or am I doing something wrong? Has anyone successfully
performed remote authentication using hessian?
This is using the 4.0.0 release.
Thanks,
Jeff
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Trunk broken?
Should trunk compile? I'm switching to 4.0.0, but still... resin-compile: module: [copy] Copying 127 files to /Users/jeff/Documents/workspace/Resin/modules/resin/classes [javac] Compiling 2524 source files to /Users/jeff/Documents/workspace/Resin/modules/resin/classes [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:33: cannot find symbol [javac] symbol : class Env [javac] location: package com.caucho.quercus.env [javac] import com.caucho.quercus.env.Env; [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:35: package com.caucho.quercus.page does not exist [javac] import com.caucho.quercus.page.QuercusPage; [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:36: cannot find symbol [javac] symbol : class ModuleContext [javac] location: package com.caucho.quercus.module [javac] import com.caucho.quercus.module.ModuleContext; [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:54: cannot find symbol [javac] symbol: class Quercus [javac] public class GoogleQuercus extends Quercus [javac]^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:60: cannot find symbol [javac] symbol : class ModuleContext [javac] location: class com.caucho.quercus.GoogleQuercus [javac] private ModuleContext _localModuleContext; [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:95: cannot find symbol [javac] symbol : class ModuleContext [javac] location: class com.caucho.quercus.GoogleQuercus [javac] protected ModuleContext createModuleContext(ModuleContext parent, [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:95: cannot find symbol [javac] symbol : class ModuleContext [javac] location: class com.caucho.quercus.GoogleQuercus [javac] protected ModuleContext createModuleContext(ModuleContext parent, [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:101: cannot find symbol [javac] symbol : class QuercusPage [javac] location: class com.caucho.quercus.GoogleQuercus [javac] public Env createEnv(QuercusPage page, [javac]^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/GoogleQuercus.java:101: cannot find symbol [javac] symbol : class Env [javac] location: class com.caucho.quercus.GoogleQuercus [javac] public Env createEnv(QuercusPage page, [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/ResinQuercus.java:33: cannot find symbol [javac] symbol : class ModuleContext [javac] location: package com.caucho.quercus.module [javac] import com.caucho.quercus.module.ModuleContext; [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/ResinQuercus.java:49: cannot find symbol [javac] symbol: class Quercus [javac] public class ResinQuercus extends Quercus [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/ResinQuercus.java:55: cannot find symbol [javac] symbol : class ModuleContext [javac] location: class com.caucho.quercus.ResinQuercus [javac] private static EnvironmentLocalModuleContext _localModuleContext [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/ResinQuercus.java:87: cannot find symbol [javac] symbol : class ModuleContext [javac] location: class com.caucho.quercus.ResinQuercus [javac] public ModuleContext getLocalContext(ClassLoader loader) [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/ResinQuercus.java:113: cannot find symbol [javac] symbol : class ModuleContext [javac] location: class com.caucho.quercus.ResinQuercus [javac] protected ModuleContext createModuleContext(ModuleContext parent, [javac] ^ [javac] /Users/jeff/Documents/workspace/Resin/modules/resin/src/com/caucho/quercus/ResinQuercus.java:113: cannot find symbol [javac] symbol : class ModuleContext [javac] location: class com.caucho.quercus.ResinQuercus [javac]
Re: [Resin-interest] Limiting session to a single IP for a given session_id
According to the security researchers who took over the torpig botnet and analyzed the data (read the PDF, it's good), some ISPs still change IP addresses a lot... more than once an hour: http://www.cs.ucsb.edu/~seclab/projects/torpig/ Jeff On Wed, May 6, 2009 at 9:09 AM, Scott Ferguson f...@caucho.com wrote: On May 4, 2009, at 7:38 AM, Daniel Lopez wrote: If Resin does not implement it itself, implementing a filter that stores the IP in the session and checks on each request before passing the request along should not be difficult. I don't know if Resin already provides such a feature. Resin doesn't currently have that feature, so you'd need to use a filter. There used to be ISPs that changed client IPs randomly as part of their normal operation. AOL was the biggest. If that behavior has changed so basically everyone uses a single client IP, we can make it an option. -- Scott S! D. S'està citant Rafael Escolar | Bookassist rafael.esco...@bookassist.com : Is there a way to force session to invalidate or not to be recognized if the client IP changes? This is a PCI requirement so that if a third obtains a valid session ID they cannot use it to re-establish the original session with the server. Based on tests I have run using resin 3.1.8, the default configuration is seems that the session is maintained whenever the JSESSIONID cookie contains a valid session id. In particular, I established a session with the resin3.1 server, then changed my client IP, then reconnected to the server and all session information was maintained. Thanks in advance. Rafa. ___ 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 mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Eclipse Plugin
Oh no... I hate this discussion. Let's just say that there are plenty of people on both sides of the fence. I have a fair amount of experience with Maven on big complicated projects and loathe it intensely. This thread is worth reading, you can search for my name to see my long-winded comment: http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html I'd rather see an ant build. For all its flaws, it's still the better Java build tool. I'd probably be willing to write and contribute a buildfile if the Powers That Be are interested. Jeff On Fri, Apr 17, 2009 at 8:41 AM, Emil Ong e...@caucho.com wrote: On Fri, Apr 17, 2009 at 03:56:43PM +0100, Stargazer wrote: Maven, maven maven Could you explain? Thanks, Emil Thanks, Emil On Mon, Apr 13, 2009 at 12:20:46PM -0500, Aaron Freeman wrote: Emil, What does the plug-in provide to us that setting up as a general application doesn't? I haven't tried the plug-in so I am not aware of what it does? Thanks, Aaron Hi Scott, The Eclipse update site isn't up just yet, but will be with the new release, due out this week or early next. Emil On Sun, Apr 12, 2009 at 09:42:24PM -0700, Scott Hernandez wrote: I noticed there is an eclipse plugin in the svn tree (artifacts/eclipse) that has seen some recent checkins. The build instructions seem pretty straight forward and end with directions to post the update-site at http://caucho.com/eclipse. When I point the eclipse updates to that address there is nothing. Is this something I can build from source? Will it be hosted there sometime soon? Is the plugin in usable form? Oh, and what do people use for an IDE btw? Thanks in advance, Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest Emil Ong Chief Evangelist Caucho Technology, Inc. Tel. (858) 456-0300 mailto:e...@caucho.com http://blog.caucho.com/ Caucho: Reliable Open Source -- Resin: application server -- Quercus: PHP in Java -- Java CanDI: contexts and dependency injection ___ 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 Emil Ong Chief Evangelist Caucho Technology, Inc. Tel. (858) 456-0300 mailto:e...@caucho.com http://blog.caucho.com/ Caucho: Reliable Open Source -- Resin: application server -- Quercus: PHP in Java -- Java CanDI: contexts and dependency injection ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.55/2057 - Release Date: 04/13/09 17:56:00 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest Emil Ong Chief Evangelist Caucho Technology, Inc. Tel. (858) 456-0300 mailto:e...@caucho.com http://blog.caucho.com/ Caucho: Reliable Open Source -- Resin: application server -- Quercus: PHP in Java -- Java CanDI: contexts and dependency injection ___ 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] Remoting without XML service declarations
Is it possible to expose EJBs (or POJOs) as remote-able objects without declaring them in XML (ie, resin-web.xml)? The Resin Remoting docs (http://caucho.com/resin/doc/resin-remoting.xtp) make it look like I must declare a servlet-mapping for every bean I wish to expose. Is there an annotation I can declare on my beans that will have the same effect? Are there any future plans to make J2EE-style InitialContext remote JNDI lookups work? Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Remoting without XML service declarations
On Tue, Mar 31, 2009 at 11:08 AM, Scott Ferguson f...@caucho.com wrote: Hmm. It might be possible to use the new Servlet 3.0 annotations for that purpose (we haven't implemented it yet.) The original idea was that exposed URLs shouldn't generally be automatic. In other words, having a class in a jar automatically listen to a URL as a servlet or a remote bean might be a security risk. Basically, the same reason why /servlets/* is discouraged. Right... I just want to be able to define those URLs without resorting to XML. The @ServletMapping annotation seems useful but you would still need something to define the protocol. As long as we're discussing wishes, I'd also like to be able to put the RMI-type protocols on a different port so that there is no chance of accidentally exposing anything :-) For now we will use the XML. Are there any future plans to make J2EE-style InitialContext remote JNDI lookups work? That should already exist with the remote-client tag. You do need to declare the remote services that you're using. But this is still within a running Resin container, right? Is there a way to make this work with a standalone client? Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Why must we define beans in xml?
Thanks... you're absolutely right. Works great. Jeff On Thu, Mar 26, 2009 at 9:40 AM, Scott Ferguson f...@caucho.com wrote: On Mar 25, 2009, at 7:27 PM, Jeff Schnitzer wrote: Is there a compelling reason why we must define our beans and services in resin-web.xml? Will this continue to be the case going forward in Resin 4.0? You don't need to define the beans in resin-web.xml. You do need a marker file like META-INF/beans.xml or META-INF/ejb-jar.xml. It's a minor nuisance, yes, but... it's nice to add a class to the project, annotate it with @Service or @Stateless or whatever, and have it automatically detected as a bean. JBoss works this way :-) If you have a META-INF/ejb-jar.xml, Resin should already pick this up. -- Scott This actually has some impact on the SubEtha code that Scott and I are working on. SubEtha plugins automatically register themselves with the container when you drop a jar file containing them into the server. This makes it easy for minimally java-savvy people to write some code, drop it in the container, and have it immediately available. Adding xml files complicates the matter. 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 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Why must we define beans in xml?
Is there a compelling reason why we must define our beans and services in resin-web.xml? Will this continue to be the case going forward in Resin 4.0? It's a minor nuisance, yes, but... it's nice to add a class to the project, annotate it with @Service or @Stateless or whatever, and have it automatically detected as a bean. JBoss works this way :-) This actually has some impact on the SubEtha code that Scott and I are working on. SubEtha plugins automatically register themselves with the container when you drop a jar file containing them into the server. This makes it easy for minimally java-savvy people to write some code, drop it in the container, and have it immediately available. Adding xml files complicates the matter. Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Perf Issues
There are profiling/memory allocation tracking tools for C and Linux... if you're seeing what looks like a memory leak, it might be worth looking into. They're quite a bit more complicated than the equivalent java tools but years ago in another life I got a lot of mileage out of Rational Purify, which has a free trial version. Jeff On Sun, Mar 22, 2009 at 10:03 AM, Rob Lockstone lockst...@mac.com wrote: On Mar 22, 2009, at 04:29, Stargazer wrote: Rob Lockstone wrote: On Mar 21, 2009, at 14:59, Stargazer wrote: Adam Allgaier wrote: I would plug jconsole into your resin instance and watch what's happening to the JVM memory. Could be loose open threads (and large thread size) that grows over time and eats up free memory. Restarting would kill all the threads and free the memory. http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html Adam Thanks, but as I'd hoped I'd made clear Resin itself shows flat memory use, whether using jconsole, jprofiler, /resin-admin or any of the other jvmti tools I've used to try to fix this. The memory consumption occurs outside java. I don't know about Ronan's problem, but yours sounds like non-java- heap memory or native memory is being exhausted. In my experience, the biggest consumers of that are threads and graphic operations. Depending on the system you're running on, your default stack size could be quite large. Have you tried setting your stack size to a much smaller value via -Xss? Unless you're doing a lot of heavy recursion, the chance that you'll need a large stack is fairly remote. On our (very busy) Windows boxes, we use a stack size of 128K (-Xss128K). Keep in mind that on a 32-bit system (not sure what you're running on), you have only 2G of addressable memory per process. So if you define a larg(ish) java heap, you have only 2G - YourHeapSize to use for allocating memory for threads and other non-java operations, such as some graphics operations. Rob How come this doesn't happen when I move the non-resin stuff (i.e. the PHP apps) to another server? Its Linux Fed 7, dual core, 1G Ram/4G swap. What I'm really asking is how can you be sure its not mod_caucho? Btw there are no graphics operations involved, and the PHP apps are all popular packages like Joomla and Pligg, so if these were at fault I'm sure the users would be screaming in their forums about it. I don't know that it's not mod_caucho. I'm only suggesting a possible cause and something to try. Iirc, at least some versions of resin (perhaps all) set their own stack size if the user does not specify one. If this is the case, it may be that the version you're using is setting a stack size that is larger than the default stack size of your OS (or larger than the stack size set by whatever other software you're using to run you PHP apps). Anyway, it's easy to set and easy to test. Rob - Original Message From: Stargazer starga...@blueyonder.co.uk To: General Discussion for the Resin application server resin-interest@caucho.com Sent: Saturday, March 21, 2009 4:39:56 AM Subject: Re: [Resin-interest] Perf Issues Ronan Lucio wrote: Hi, We have had a perf issue. Our servers have 4Gb RAM. It has just Resin and Apache installed. The problem is, when I start Resin, the whole server uses about 2.5 Gb RAM After that memory usage keep growing til it reachs the 4Gb RAM, use swap and so on. After few hours the application start getting slow. Analyzing the server sources, it's using so low CPU, load about 1... I see none overload evidence, except for RAM memory. So I just restart Resin and/or Apache and application gets fast again, but few ours later it will raise the same issue. I have been suffering from exactly those symptoms for years. Do your httpd processes consume all the swap, with top showing some at 450Mb? (default httpd.conf values) I.e does restarting apache alone, and not resin, cause the swap to drop back down to normal until the next slow growth starts it all again? That is my pattern. So when I profile resin theres no unusual growth even through the whole server is effectiviley dead until restart. Given that, whos to blame? Could mod_caucho somehow be at fault even though resin itself is ok? I have another identical server running a couple of PHP CMS apps, no resin or java in sight - because of this problem actually. The plan is to move everything over when stable but these have become too critical to play with. Their typical httpd swap use is 25Mb, and its the default httpd.conf. I would dearly love to know what the httpd on the failing server thinks it needs to hold onto 450Mb for, without tweaking there could be 20 of these. There are other non-quercus PHP apps running on that server btw. My solution is to kill child httpd processes at a far quicker rate than you'd normally want, and it works of sorts: IfModule prefork.c StartServers 8
Re: [Resin-interest] Perf Issues
It's also worth mentioning that for serious application tuning, there is no substitute for a good profiling tool. In the past I have had great results with JProfiler: http://www.ej-technologies.com/products/jprofiler/overview.html I've even gone so far as to take one node in a production cluster, give it a reduced load profile at the balancer (because profiling slows things down considerably), and run the profiler against it live. You'll be amazed what you discover. Jeff On Sat, Mar 21, 2009 at 7:39 AM, Adam Allgaier allgai...@yahoo.com wrote: I would plug jconsole into your resin instance and watch what's happening to the JVM memory. Could be loose open threads (and large thread size) that grows over time and eats up free memory. Restarting would kill all the threads and free the memory. http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html Adam - Original Message From: Stargazer starga...@blueyonder.co.uk To: General Discussion for the Resin application server resin-interest@caucho.com Sent: Saturday, March 21, 2009 4:39:56 AM Subject: Re: [Resin-interest] Perf Issues Ronan Lucio wrote: Hi, We have had a perf issue. Our servers have 4Gb RAM. It has just Resin and Apache installed. The problem is, when I start Resin, the whole server uses about 2.5 Gb RAM After that memory usage keep growing til it reachs the 4Gb RAM, use swap and so on. After few hours the application start getting slow. Analyzing the server sources, it's using so low CPU, load about 1... I see none overload evidence, except for RAM memory. So I just restart Resin and/or Apache and application gets fast again, but few ours later it will raise the same issue. I have been suffering from exactly those symptoms for years. Do your httpd processes consume all the swap, with top showing some at 450Mb? (default httpd.conf values) I.e does restarting apache alone, and not resin, cause the swap to drop back down to normal until the next slow growth starts it all again? That is my pattern. So when I profile resin theres no unusual growth even through the whole server is effectiviley dead until restart. Given that, whos to blame? Could mod_caucho somehow be at fault even though resin itself is ok? I have another identical server running a couple of PHP CMS apps, no resin or java in sight - because of this problem actually. The plan is to move everything over when stable but these have become too critical to play with. Their typical httpd swap use is 25Mb, and its the default httpd.conf. I would dearly love to know what the httpd on the failing server thinks it needs to hold onto 450Mb for, without tweaking there could be 20 of these. There are other non-quercus PHP apps running on that server btw. My solution is to kill child httpd processes at a far quicker rate than you'd normally want, and it works of sorts: IfModule prefork.c StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 96 /IfModule IfModule worker.c StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 96 /IfModule This problem usually happens on peaks hours. So we upgraded RAM memory to 8Gb with a PAE kernel. Although it doesn't reach the 8G RAM, slow moments gots for frequent. It seems to work worse that way (8Gb + PAE kernel). The question is: Is there everyone having the same issue with Resin (3.1.6)? My doubt if such problem resides either on Resin or on my application. All versions prior to 3.1.6, and currently with 3.2.1 Pro Thanks, Ronan ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.21/2014 - Release Date: 03/20/09 06:59:00 ___ 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 mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Remote programmatic authentication
Answering my own question #1, I found the HessionProxyFactory.setUser() and setPassword() methods. Great. #2 is still a mystery to me. I'm in a servlet, how do I programmatically tell the container to log me in with a username and password? Thanks, Jeff On Thu, Mar 19, 2009 at 2:08 PM, Jeff Schnitzer j...@infohazard.org wrote: First of all, I'd just like to say wow, I'm happy to re-discover Resin - I recall using it briefly in 2002 and I'm impressed with what you've been doing since. It's a sharp contrast to the progress of JBoss, which has sadly become a complete wreck in the last few years. The web beans stuff is fantastic and you're way ahead of the game. I've read most of the docs now and I'm a bit confused about how you authenticate to the container in two different scenarios: #1) A remote caller using hessian, either from another Resin instance (using DI) or from a standalone client. I presume at a protocol level this involves basic or digest auth, but I don't see the API hooks. #2) Within the container, how do you authenticate programmatically? Ie, not using login forms or basic auth. This is the common case of a signup form; after the user has filled out their chosen username and password I want to authenticate them to the container without forcing them to re-enter the credentials. Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Remote programmatic authentication
Thanks, but that is not what I'm looking for. The document describes building an authentication source and using automatic authentication (aka web.xml security constraints). The problem is, j2ee automatic authentication is nearly useless. It doesn't allow for autologin cookies nor does it allow me to sign up new users - they would have to then log in again. It blows my mind that a decade later the servlet spec hasn't addressed these simple needs. I need a way, in my web app, to programmatically say to the container authenticate as this user/pass. Then these credentials will be used for further calls into the EJB tier or for responding to HttpServletRequest.isUserInRole() calls. Of course at the SPI level these will end up calling into my Resin Authenticator. This is a pretty common problem, there must be a Resin way to do it. In JBoss5, it looks like this: SecurityClient securityClient = SecurityClientFactory.getSecurityClient(); securityClient.setSimple(user, password); securityClient.login(); Thanks, Jeff On Thu, Mar 19, 2009 at 7:38 PM, Aaron Freeman aaron.free...@layerz.com wrote: #2 is still a mystery to me. I'm in a servlet, how do I programmatically tell the container to log me in with a username and password? This page has a good overview of how to do it: http://www.informit.com/articles/article.aspx?p=24253seqNum=7 So you set up your security constraints in your resin.xml and reference a custom authenticator inside the login-config. The create your custom authenticator by AbstractAuthenticator. Note the code in the example is referencing: com.caucho.server.http.AbstractAuthenticator but I think you want to extend com.caucho.server.AbstractAuthenticator instead, as I think the .http. version is deprecated. - Aaron ___ 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
