[Resin-interest] InjectManager not binding generified class?
The inject manager isn't adding this class to the registered beans. I
have seen a few issues with Generic classes with matching classes but
this ones seems pretty straight forward.
Does anything anyone know why this isn't picked up and registered in
the inject manager?
@New
public class InjectBeanHelperT {
@Current Manager mgr;
public InjectBeanHelper(){}
@SuppressWarnings(unchecked)
public T getInstance(String clazz){
T o = null;
Class? extends T tc = null;
try {
tc = (Class? extends T) Class.forName(clazz);
o = (T)mgr.getInstanceByType(tc);
}catch(ClassNotFoundException e){}
if(o==null) o = (T)mgr.getInstanceByName(clazz);
return o;
}
public T getInstance(Class? extends T clazz){
return this.mgr.getInstanceByType(clazz);
}
}
I'm still working against trunk :)
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] About editing resin.conf
H.Päiväniemi schrieb: Resin seems to crash if I open resin.conf for editing with vi etc. Why? How can I configure resin not to do that? I have 5 resin servers and resin.conf is symlinked to nfs on all servers so if I just open resin.conf, all servers will crash... Access over NFS may be the issue here. Try reading the file over NFS from one of your Resin servers while you're editing it in VI, or any other editor, for that matter. Does that work? There must be some parameters to prevent this kind of feature... You could make your edits on a copy of the resin.conf. Saving the file in an invalid state might also be problematic. Michael Ludwig ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Stack overflow on resin-web.xml load
On May 5, 2009, at 11:08 AM, Scott Hernandez wrote:
I'm a little stumped on this one. I'm guessing that there is some kind
of circular dep. in the classes (EJBs), but where is the question...
I've added a bug report at http://bugs.caucho.com/view.php?id=3480
The circular dependency problem can be a bit tricky internally,
particularly in combination with EL expressions. The CanDI spec does
have some support for circular dependencies, but there's a bit of
extra work that Resin needs to do to make it work.
-- Scott
[09-05-05 10:58:42.741] {main} resin:import
'c:\src\caucho\resin\webapps\subetha\WEB-INF\resin-web.xml'
log4j:WARN No appenders could be found for logger
(org.subethamail.core.smtp.SMTPService).
log4j:WARN Please initialize the log4j system properly.
[09-05-05 10:58:46.286] {main}
file:/c:/src/caucho/resin/conf/app-default.xml:240:
com.caucho.config.core.ResinImport.init():
java.lang.StackOverflowError
[09-05-05 10:58:46.286] {main}
[09-05-05 10:58:46.286] {main} 238: resin:import
path=WEB-INF/resin-web-pre.xml optional=true/
[09-05-05 10:58:46.286] {main} 239: resin:import
path=WEB-INF/web.xml optional=true/
[09-05-05 10:58:46.286] {main} 240: resin:import
path=WEB-INF/resin-web.xml optional=true/
[09-05-05 10:58:46.286] {main} 241: resin:import
path=WEB-INF/resin-web-post.xml optional=true/
[09-05-05 10:58:46.286] {main} 242: /web-app-default
[09-05-05 10:58:46.286] {main}
[09-05-05 10:58:46.286] {main} at
com.caucho.config.ConfigContext.error(ConfigContext.java:1309)
[09-05-05 10:58:46.286] {main} at
com
.caucho.config.ConfigContext.configureChildNode(ConfigContext.java:
496)
[09-05-05 10:58:46.286] {main} at
com
.caucho.config.ConfigContext.configureAttribute(ConfigContext.java:
364)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.config
.program.NodeBuilderChildProgram.inject(NodeBuilderChildProgram.java:
71)
[09-05-05 10:58:46.286] {main} at
com
.caucho.config.program.ContainerProgram.inject(ContainerProgram.java:
80)
[09-05-05 10:58:46.286] {main} at
com.caucho.config.program.ConfigProgram.configure(ConfigProgram.java:
70)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server
.deploy
.EnvironmentDeployController
.configureInstance(EnvironmentDeployController.java:381)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server
.deploy
.EnvironmentDeployController
.configureInstance(EnvironmentDeployController.java:55)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server.deploy.DeployController.startImpl(DeployController.java:676)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server
.deploy
.StartAutoRedeployAutoStrategy
.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server.deploy.DeployController.startOnInit(DeployController.java:549)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:
160)
[09-05-05 10:58:46.286] {main} at
com
.caucho.server.webapp.WebAppContainer.startImpl(WebAppContainer.java:
707)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.host.Host.startImpl(Host.java:496)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.webapp.WebAppContainer.start(WebAppContainer.java:
687)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server.deploy.DeployController.startImpl(DeployController.java:678)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server
.deploy
.StartAutoRedeployAutoStrategy
.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[09-05-05 10:58:46.286] {main} at
com
.caucho
.server.deploy.DeployController.startOnInit(DeployController.java:549)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:
160)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.host.HostContainer.start(HostContainer.java:484)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.cluster.Server.start(Server.java:1822)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.resin.Resin.createServer(Resin.java:927)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.resin.Resin.start(Resin.java:998)
[09-05-05 10:58:46.286] {main} at
com.caucho.server.resin.Resin.initMain(Resin.java:1462)
...
Here is the resin-web.xml
(http://subetha.googlecode.com/svn/branches/resin/web/WEB-INF/resin-web.xml
)
web-app xmlns=http://caucho.com/ns/resin;
xmlns:resin=urn:java:com.caucho.resin
xmlns:cfg=urn:java:com.caucho.config
xmlns:jms=urn:java:com.caucho.jms
xmlns:ejb=urn:java:com.caucho.ejb
xmlns:adm=urn:java:org.subethamail.core.admin
xmlns:util=urn:java:org.subethamail.core.util
xmlns:ss=urn:java:org.subethamail.web.security
xmlns:queue=urn:java:org.subethamail.core.queue
logger name=com.caucho.config level=severe/
!-- These (specifically the ResingLogin) seems to cause the injector
to find
Re: [Resin-interest] Limiting session to a single IP for a given session_id
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
Re: [Resin-interest] About editing resin.conf
On Wed, May 06, 2009 at 09:56:31AM +0300, H.Päiväniemi wrote: Hi all, I just subscribed to this list. Please, could you gimme advice for this problem - I believe this has been on the wall many times in the history, but still... Resin seems to crash if I open resin.conf for editing with vi etc. Why? How can I configure resin not to do that? Can you describe how Resin crashes? I have 5 resin servers and resin.conf is symlinked to nfs on all servers so if I just open resin.conf, all servers will crash... There must be some parameters to prevent this kind of feature... When using NFS, you should disable dependency checking on files. Set dependency-check-interval-1/dependency-check-interval Emil 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
Re: [Resin-interest] About editing resin.conf
On May 6, 2009, at 9:29 AM, Emil Ong wrote: On Wed, May 06, 2009 at 09:56:31AM +0300, H.Päiväniemi wrote: Hi all, I just subscribed to this list. Please, could you gimme advice for this problem - I believe this has been on the wall many times in the history, but still... Resin seems to crash if I open resin.conf for editing with vi etc. Why? How can I configure resin not to do that? Can you describe how Resin crashes? To followup, when you modify the resin.conf, Resin should restart. That's normal behavior. -- Scott I have 5 resin servers and resin.conf is symlinked to nfs on all servers so if I just open resin.conf, all servers will crash... There must be some parameters to prevent this kind of feature... When using NFS, you should disable dependency checking on files. Set dependency-check-interval-1/dependency-check-interval Emil 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
Re: [Resin-interest] InjectManager not binding generified class?
On May 6, 2009, at 2:21 AM, Scott Hernandez wrote:
The inject manager isn't adding this class to the registered beans. I
have seen a few issues with Generic classes with matching classes but
this ones seems pretty straight forward.
Does anything anyone know why this isn't picked up and registered in
the inject manager?
I'm not sure that @New is supposed to be allowed on the class itself,
but that part of the spec has been changing a bit.
But the main issue is that generic classes are not simple beans,
because the generic type is part of the Java Injection matching
algorithm. In other words, you can register a FooString (using a
producer method), but not a FooX, because that's not a complete type.
In other words, if you want to register a parameterized class, you
currently need to have a @Produces factory for the class.
-- Scott
@New
public class InjectBeanHelperT {
@Current Manager mgr;
public InjectBeanHelper(){}
@SuppressWarnings(unchecked)
public T getInstance(String clazz){
T o = null;
Class? extends T tc = null;
try {
tc = (Class? extends T) Class.forName(clazz);
o = (T)mgr.getInstanceByType(tc);
}catch(ClassNotFoundException e){}
if(o==null) o = (T)mgr.getInstanceByName(clazz);
return o;
}
public T getInstance(Class? extends T clazz){
return this.mgr.getInstanceByType(clazz);
}
}
I'm still working against trunk :)
___
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] Stack overflow on resin-web.xml load
Fair enough. Is there any way of debugging this, or detecting which injections are the cause of the problem(s)? It is fairly hard to get a debugger into the situation as these are such common operations in th injection system and I don't know which classes (injection cases) are the cause. On Wed, May 6, 2009 at 8:48 AM, Scott Ferguson f...@caucho.com wrote: On May 5, 2009, at 11:08 AM, Scott Hernandez wrote: I'm a little stumped on this one. I'm guessing that there is some kind of circular dep. in the classes (EJBs), but where is the question... I've added a bug report at http://bugs.caucho.com/view.php?id=3480 The circular dependency problem can be a bit tricky internally, particularly in combination with EL expressions. The CanDI spec does have some support for circular dependencies, but there's a bit of extra work that Resin needs to do to make it work. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
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
[Resin-interest] JavaMail Session Injection
I'd like to inject a Session into a few of my beans. I believe the
correct way to do this is to use the
@Resource(name=java:comp/env/mail) annotation, but I would like to
be less verbose (if possible), and just use @Current, so I have done
the following:
@ApplicationScoped
public class Producers {
@Resource(name=java:comp/env/jdbc/subetha)
DataSource ds;
@Resource(name=java:comp/env/mail)
Session ses;
@Produces //@Name(subetha)
Session createMailSession(){
return this.ses;
}
@Produces @Name(subetha)
DataSource createSubethaDS(){
return this.ds;
}
}
But this produces a stack overflow with reference to the sess field
injection. It seems like it is actually getting this producer factory
from the inject manager and trying to use its own createMailSession
method (recursively) to do the injection.This seems very bad :( , or
have i misunderstood how this is supposed to work?
Thanks in advance,
Scott
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] watchdog stop authentication failure
Hi, Does anybody knows what can cause this error? --- [2009/05/06 16:18:16.552] watchdog stop authentication failure [2009/05/06 16:18:16.552] com.caucho.config.ConfigException: watchdog stop forbidden - authentication failed [2009/05/06 16:18:16.552] at com.caucho.boot.WatchdogServlet.stop(WatchdogServlet.java:92) [2009/05/06 16:18:16.552] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [2009/05/06 16:18:16.552] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [2009/05/06 16:18:16.552] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [2009/05/06 16:18:16.552] at java.lang.reflect.Method.invoke(Method.java:597) [2009/05/06 16:18:16.552] at com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:180) [2009/05/06 16:18:16.552] at com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:109) [2009/05/06 16:18:16.552] at com.caucho.hessian.server.HessianServlet.service(HessianServlet.java:396) [2009/05/06 16:18:16.552] at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103) [2009/05/06 16:18:16.552] at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187) [2009/05/06 16:18:16.552] at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266) [2009/05/06 16:18:16.552] at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:435) [2009/05/06 16:18:16.552] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:678) [2009/05/06 16:18:16.552] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721) [2009/05/06 16:18:16.552] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643) [2009/05/06 16:18:16.552] at java.lang.Thread.run(Thread.java:619) --- I'm running Resin-Pro 3.1.6. No lucky researching about that in google. Thanks, Ronan ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] watchdog stop authentication failure
As far as I remember, I have experienced this once when changing the
resin.conf and modifying (or adding) a user/ to management/ while Resin
was started
management path=${resin.root}/admin
user name=admin password=password==/
...
The change in resin.conf caused Resin to restart but trying to stop it was
unsuccessful - similar to your exception. You could try to kill the watchdog
and resin processes and start both again afterwards - then 'stop' should be
working again.
Best Regards,
Steffen
2009/5/6 Ronan Lucio lis...@tiper.com.br
Hi,
Does anybody knows what can cause this error?
---
[2009/05/06 16:18:16.552] watchdog stop authentication failure
[2009/05/06 16:18:16.552] com.caucho.config.ConfigException: watchdog
stop forbidden - authentication failed
[2009/05/06 16:18:16.552] at
com.caucho.boot.WatchdogServlet.stop(WatchdogServlet.java:92)
[2009/05/06 16:18:16.552] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2009/05/06 16:18:16.552] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[2009/05/06 16:18:16.552] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[2009/05/06 16:18:16.552] at
java.lang.reflect.Method.invoke(Method.java:597)
[2009/05/06 16:18:16.552] at
com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:180)
[2009/05/06 16:18:16.552] at
com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:109)
[2009/05/06 16:18:16.552] at
com.caucho.hessian.server.HessianServlet.service(HessianServlet.java:396)
[2009/05/06 16:18:16.552] at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[2009/05/06 16:18:16.552] at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[2009/05/06 16:18:16.552] at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266)
[2009/05/06 16:18:16.552] at
com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:435)
[2009/05/06 16:18:16.552] at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:678)
[2009/05/06 16:18:16.552] at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
[2009/05/06 16:18:16.552] at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
[2009/05/06 16:18:16.552] at java.lang.Thread.run(Thread.java:619)
---
I'm running Resin-Pro 3.1.6.
No lucky researching about that in google.
Thanks,
Ronan
___
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] watchdog stop authentication failure
Hi Steffen,
Thank you very much,
I think it's my case, too.
After changing resin.conf I executed a restart.
It probably doesn't.
Thank you,
Ronan
Steffen Busch escreveu:
As far as I remember, I have experienced this once when changing the
resin.conf and modifying (or adding) a user/ to management/ while
Resin was started.
...
management path=${resin.root}/admin
user name=admin password=password==/
...
The change in resin.conf caused Resin to restart but trying to stop it
was unsuccessful - similar to your exception. You could try to kill
the watchdog and resin processes and start both again afterwards -
then 'stop' should be working again.
Best Regards,
Steffen
2009/5/6 Ronan Lucio lis...@tiper.com.br mailto:lis...@tiper.com.br
Hi,
Does anybody knows what can cause this error?
---
[2009/05/06 16:18:16.552] watchdog stop authentication failure
[2009/05/06 16:18:16.552] com.caucho.config.ConfigException: watchdog
stop forbidden - authentication failed
[2009/05/06 16:18:16.552] at
com.caucho.boot.WatchdogServlet.stop(WatchdogServlet.java:92)
[2009/05/06 16:18:16.552] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2009/05/06 16:18:16.552] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[2009/05/06 16:18:16.552] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[2009/05/06 16:18:16.552] at
java.lang.reflect.Method.invoke(Method.java:597)
[2009/05/06 16:18:16.552] at
com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:180)
[2009/05/06 16:18:16.552] at
com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:109)
[2009/05/06 16:18:16.552] at
com.caucho.hessian.server.HessianServlet.service(HessianServlet.java:396)
[2009/05/06 16:18:16.552] at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
[2009/05/06 16:18:16.552] at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
[2009/05/06 16:18:16.552] at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266)
[2009/05/06 16:18:16.552] at
com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:435)
[2009/05/06 16:18:16.552] at
com.caucho.server.port.TcpConnection.run(TcpConnection.java:678)
[2009/05/06 16:18:16.552] at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
[2009/05/06 16:18:16.552] at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
[2009/05/06 16:18:16.552] at java.lang.Thread.run(Thread.java:619)
---
I'm running Resin-Pro 3.1.6.
No lucky researching about that in google.
Thanks,
Ronan
___
resin-interest mailing list
resin-interest@caucho.com mailto: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
