Re: [Resin-interest] new snapshot available
When i try and make the 080111 snapshot I get make: *** No rule to make target `Makefile.am', needed by `Makefile.in'. Stop. Alex -Original Message- From: [EMAIL PROTECTED] on behalf of Scott Ferguson Sent: Fri 11/01/2008 22:08 To: General Discussion for the Resin application server Subject: [Resin-interest] new snapshot available A new snapshot is available. We've just finished week 4 of the 8- week release cycle for 3.1.5, so there's another 4 weeks to go. The snapshot is still a bit unstable do to the configuration changes, but a number of people have been asking for it to check on some bug fixes. The snapshot is also available using maven2 at http://caucho.com/m2- snapshot. There's a wiki page at http://wiki.caucho.com/Maven2. Also, the snapshot includes the struts2 integration with Resin's IoC injection. The wiki page is at http://wiki.caucho.com/Struts2. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest winmail.dat* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] logging is too fine, 3.0.24 and 3.1
The code differences between 3.0.24 and 3.1.4 snapshot imply that this issue also exists in 3.1, so I've edited my question and resent it. Aside from innocuous changes to import statements, postconstruct annotation and comments, the three significant fixes are: a fix to jmx registration of the sublogger (LogConfig), a fix to use local handlers instead of super.log to publish log messages (EnvironmentLogger), and a fix to el variable evaluation. Added classes are AbstracRolloverLog, EnvironmentStream, RotateString, TimestampFilter. I don't think these differences will affect this issue. John J. Franey wrote: Here is an excerpt of my logging config in resin.conf: ... host ... web-app ... log path=... timestamp=... format=... logger name=com.corp level=fine logger name=com.corp.deep.package level=info/ /web-app /host .. The problem is that the loggers at or below com.corp.deep.package are writing out fine log messages. In a regular java app, if I configured logging in a logging.properties to something similar, fine log messages from com.corp.deep.package loggers would not be written out. Thanks -- View this message in context: http://www.nabble.com/logging-is-too-fine%2C-3.0.24-tp14789229p14801901.html Sent from the Resin mailing list archive at Nabble.com. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin clustered session store
Thanks for the response Scott. We did some firewall reconfiguration with regards to connections and sessions and the issue appears to have gone away. I've not tried the 3.1 branch in a while as we found it didn't play well with XFire, but I will upgrade to 3.0.25 ASAP. rgds, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 14 January 2008 16:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Jan 10, 2008, at 4:19 AM, Richard Grantham wrote: Hi list, I'm using Resin Pro 3.0.23 (2 servers, load balanced/distributed sessions) and I've seen this error a few times in the log file: We've made a few fixes to the synchronization/timing of the clustered session. Some in 3.0.25, but many more in 3.1. However, I was never able to reproduce that exact error here, so if anyone runs into this on 3.1.4 or later, it would be very helpful to send a bug report on the issue with as much detail as possible. -- Scott [2008-01-10 11:31:01.379] java.io.EOFException [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$PeekInputStream.readFully (ObjectInputStream.ja va:2279) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$BlockDataInputStream.readShort (ObjectInputStre am.java:2748) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.init(ObjectInputStream.java:280) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject $DistributedObjectInputStream.in it(ClusterObject.java:474) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:286) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:423) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:259) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionManager.getSession (SessionManager.java: 1278) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.createSession (AbstractH ttpRequest.java:1444) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractHttp Request.java:1256) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.writeHeaders (AbstractH ttpResponse.java:1556) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeHeaders (ResponseStream. java:216) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeNext (ResponseStream.jav a:401) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushByteBuffer (ToByte ResponseStream.java:518) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushBuffer (ToByteResp onseStream.java:424) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.finish (ResponseStream.java:6 64) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.close (ResponseStream.java:79 6) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.finish (AbstractHttpRes ponse.java:1956) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.close (AbstractHttpResp onse.java:260) [2008-01-10 11:31:01.379] at com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.ja va:190) [2008-01-10 11:31:01.379] at com.caucho.server.dispatch.ServletInvocation.service (ServletInvocation.j ava:229) [2008-01-10 11:31:01.379] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) [2008-01-10 11:31:01.379] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.run(ThreadPool.java:442) [2008-01-10 11:31:01.379] at java.lang.Thread.run(Thread.java: 619) The servers are configured to persist sessions across the cluster. On both servers the size of the DB file is 500M. It doesn't grow or shrink. Is this normal? I'm concerned as to what's causing the above error. The (hardware) load balancer has been reporting that it has reached it's maximum number of sessions. Could this be playing a part? Any assistance would be appreciated. rgds, Richard Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd
Re: [Resin-interest] LDAP and resin
On Jan 11, 2008, at 6:29 AM, Vinny wrote: Do any of the 2 authentication schemes for LDAP (JndiLoginModule or LdapAuthenticator) support either simple or anonymous authentication? The docs are kind of thin in that regard. I've just added a bug report as http://bugs.caucho.com/view.php?id=2325. The LDAP authentication is just a trivial wrapper around the LdapCtxFactory of JNDI. So there's no special logic, unless those names are already supported by LdapCtxFactory. -- Scott -- The Street Programmer http://streetprogrammer.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] J2EE Listeners order
Scott, Thanks for your response. I added my listener to the web-app-default section in the app-default.xml file. before the import of the web application's web.xml and that solved the problem. Thanks Sashi On 1/14/08, Scott Ferguson [EMAIL PROTECTED] wrote: On Jan 10, 2008, at 4:03 PM, Sashidhar Guduri wrote: Servlet 2.4 spec guarantees the order of the listener creation is the order in which they are specified in the web.xml. In Resin, if I specify a listener in the web-app-default part of resin.conf, how do I make sure that one is created before the ones specified in the web.xml. Is that even possible? The order is the same as in the resin.conf. web-app-defaults are applied before any explicit web-app The trick, though, is that WEB-INF/web.xml and WEB-INF/resin-web.xml are defined in resin/conf/app-default.xml in a web-app-default. So, it matters where your web-app-default is. If it's before the resin:import of app-default.xml, it will be applied first. You can change the order a bit by using a prologue tag around your defaults. Resin really does two passes: 1. all the web-app-default values with a prologue 2. all the web-app-default values outside the prologue -- Scott Thanks Sashi ___ 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] class loader question on linux?
On Jan 11, 2008, at 9:26 PM, Vic Cekvenich wrote:
I wonder if someone on the list has an idea as to what to try in
this situation.
I used to in resin 2.x use the class loader hack config, not sure
now why.
You should remove that. It should never be enabled. It only exists
as a compatibility configuration for an old version of the servlet
spec that incorrectly defined class loader order.
The java classes for any JNI code should normally be at the system
classloader level, e.g. in resin/ext-lib, not in WEB-INF/lib.
The JDK only lets you load a native library once, which causes all
kinds of problems with web-app reloading. So you want to put JNI
code at the system level so it's never reloaded.
-- Scott
I now have potentially a class loader issue loading native code,
but ... no hints I get from logs.
The code bellow I am using, works great in Resin nightly on windoze
in the container. It works great on Linux (Fedora 7) in Java
outside of resin servlet.
But it fails to ... parse when inside the resin container, it just
returns blank and no traces or logs.
One time it said:
UnsatisfiedLinkError: Native Library already loaded in another
classloader
But no errors anymore show up. In any case I moved needed loading
jars to resin/lib and .so files are in LD_PATH and CLASSPATH.
I wonder what I should try to debug? Anyone?
Even if there's a link on the resin 3.x classloader hack if any,
or .. a link to educate me more on native java integration or on
how to hook up remote resin to debug,jconsole,jmx or to slap me for
a something silly.
There is some google on resin's class loader and on the error I got
above once but not more. Again works on Windoze and on linux
outside of the container
Stumped,
.V
ps: here is the class, basically a System.Load.
boolean isParsing = false;
static boolean isInitialized = false;
DomDocumentBuilder domBuilder = new DomDocumentBuilder();
private static String MInitializedJvmProperty =
MParser.Initialized;
/**
* initialize the XPCOM embedded components with the proper
* components base directory
*
* @param componentBase
*/
private synchronized static native void initXPCOM(String
componentBase)throws ParserInitializationException;
/**
* Native function. parse an html function using m parser and
* make callbacks to the java local sink ( DomDocumentBuilder for
that
* matter)
*
* @param html
*HTML to parse.
* @throws ParserInitializationException
*/
public native void parseHtml(String html) throws
ParserInitializationException;
/**
*
* A callback is being made from native code to this function.
*
* @param domOperation
* @param domArgument
*/
public synchronized void callback(String domOperation, String
domArgument)
{
// System.out.println(called back with :+domOperation + +
domArgument );
domBuilder.addInstruction(domOperation, domArgument);
}
public Document parse(String html) throws DocumentException
{
this.domBuilder.reset();
try
{
this.parseHtml(html);
}
catch (Throwable e)
{
System.err.println(Warning: could not parse html : +
e.getMessage());
throw new DocumentException(e);
}
return this.domBuilder.buildDocument();
}
public void dump() {
this.domBuilder.dump();
}
/**
* Initialize the parser with a DLL to load and
* component base
*
* @param dllToLoad
* @param componentsBase
* @throws ParserInitializationException
*/
public static void init(String parserLibrary, String
componentsBase) {
String initialized = System.getProperty(MnitializedJvmProperty);
System.out.println(loaded + initialized );
if (initialized == null)
{
System.setProperty(MInitializedJvmProperty, true);
}
else
{
System.err.println(Warning : Parser detected an
additional
attempt to initialize XPCOM. operation ignored.);
return;
}
try
{
//ClassLoader sysCl =
ClassLoader.getSystemClassLoader();
System.load(parserLibrary);
initXPCOM(componentsBase);
System.out.println(loaded);
}
catch (Exception e)
{
Re: [Resin-interest] mod_rewrite question
that would be great ... but it somehow needs to recognize that the
file is missing so that the default file can be sent ...
can that be done with the rewrite dispatch tags ... or perhaps the
error tags with the exception attributes ... ??
On Jan 14, 2008, at 12:06 PM, Scott Ferguson wrote:
On Jan 11, 2008, at 6:00 PM, Arthur Naylor wrote:
hello !!
i've read elsewhere that this should work fine but am not able to
get the mod_rewrite condition and rule to affect the serving of
resin's 404 instead of my default image ...
Once the request gets to Resin, mod_rewrite doesn't affect
anything. So this sounds like it would be something that needs to
be configured on the Resin end of things, e.g. with the rewrite-
dispatch tag (http://caucho.com/resin/doc/rewrite-tags.xtp)
-- Scott
any leads would be very helpful
thanks !!
On Jan 11, 2008, at 9:10 AM, Arthur Naylor wrote:
hello !!
am trying to use apache's mod_rewrite for missing JPGs using a
default JPG ...
my .htaccess file has ...
RewriteEngine on
RewriteBase /
# missing images
RewriteCond %{REQUEST_URI} !-U
RewriteRule .*\.jpg$ /assets/default.jpg [L,PT]
but resin is still sending back its 404 ... when i request a missing
JPG from a page on the site ...
any ideas ???
___
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 mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] logging is too fine, 3.0.24 and 3.1
On Jan 14, 2008, at 5:56 AM, John J. Franey wrote: The code differences between 3.0.24 and 3.1.4 snapshot imply that this issue also exists in 3.1, so I've edited my question and resent it. Aside from innocuous changes to import statements, postconstruct annotation and comments, the three significant fixes are: a fix to jmx registration of the sublogger (LogConfig), a fix to use local handlers instead of super.log to publish log messages (EnvironmentLogger), and a fix to el variable evaluation. Added classes are AbstracRolloverLog, EnvironmentStream, RotateString, TimestampFilter. I don't think these differences will affect this issue. Thanks, John. I've filed this as http://bugs.caucho.com/view.php? id=2327 -- Scott John J. Franey wrote: Here is an excerpt of my logging config in resin.conf: ... host ... web-app ... log path=... timestamp=... format=... logger name=com.corp level=fine logger name=com.corp.deep.package level=info/ /web-app /host .. The problem is that the loggers at or below com.corp.deep.package are writing out fine log messages. In a regular java app, if I configured logging in a logging.properties to something similar, fine log messages from com.corp.deep.package loggers would not be written out. Thanks -- View this message in context: http://www.nabble.com/logging-is-too- fine%2C-3.0.24-tp14789229p14801901.html Sent from the Resin mailing list archive at Nabble.com. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] javax.mail.Session - JNDI
On Jan 12, 2008, at 6:21 PM, Ron Pitts wrote: I've setup a entry wiithn resin.conf as follows resource jndi-name=mail/MailSession type=javax.mail.Session init mail.store.protocolimap/mail.store.protocol mail.transport.protocolsmtp/mail.transport.protocol mail.imap.hostsomedomain.com/mail.imap.host mail.pop3.hostsomedomain.com/mail.pop3.host mail.smtp.host somedomain.com/mail.smtp.host mail.smtp.passwordsomepassword/mail.smtp.password mail.smtp.usersomeuser/mail.smtp.user mail.smtp.authtrue/mail.smtp.auth /init /resource However, I'm getting javax.mail.AuthenticationFailedException when trying to send the message, looks like I cant use JNDI to pass the username password because it requires some Authenticator object? I've added a bug report as http://bugs.caucho.com/view_all_bug_page.php I think we'll want a mail-session tag to make this clearer. I'm not sure what the Authenticator issue is. It's not related to Resin's authenticators. As a workaround, you might need to set the system-property values instead. -- Scott 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 clustered session store
On Mon, Jan 14, 2008 at 04:54:19PM -, Richard Grantham wrote: Thanks for the response Scott. We did some firewall reconfiguration with regards to connections and sessions and the issue appears to have gone away. I've not tried the 3.1 branch in a while as we found it didn't play well with XFire, but I will upgrade to 3.0.25 ASAP. Hi Richard, What problems did you run into with XFire and 3.1? We want to make sure they work well together. Thanks, Emil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 14 January 2008 16:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Jan 10, 2008, at 4:19 AM, Richard Grantham wrote: Hi list, I'm using Resin Pro 3.0.23 (2 servers, load balanced/distributed sessions) and I've seen this error a few times in the log file: We've made a few fixes to the synchronization/timing of the clustered session. Some in 3.0.25, but many more in 3.1. However, I was never able to reproduce that exact error here, so if anyone runs into this on 3.1.4 or later, it would be very helpful to send a bug report on the issue with as much detail as possible. -- Scott [2008-01-10 11:31:01.379] java.io.EOFException [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$PeekInputStream.readFully (ObjectInputStream.ja va:2279) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$BlockDataInputStream.readShort (ObjectInputStre am.java:2748) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.init(ObjectInputStream.java:280) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject $DistributedObjectInputStream.in it(ClusterObject.java:474) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:286) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:423) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:259) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionManager.getSession (SessionManager.java: 1278) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.createSession (AbstractH ttpRequest.java:1444) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpRequest.getSession (AbstractHttp Request.java:1256) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.writeHeaders (AbstractH ttpResponse.java:1556) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeHeaders (ResponseStream. java:216) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.writeNext (ResponseStream.jav a:401) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushByteBuffer (ToByte ResponseStream.java:518) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ToByteResponseStream.flushBuffer (ToByteResp onseStream.java:424) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.finish (ResponseStream.java:6 64) [2008-01-10 11:31:01.379] at com.caucho.server.connection.ResponseStream.close (ResponseStream.java:79 6) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.finish (AbstractHttpRes ponse.java:1956) [2008-01-10 11:31:01.379] at com.caucho.server.connection.AbstractHttpResponse.close (AbstractHttpResp onse.java:260) [2008-01-10 11:31:01.379] at com.caucho.server.webapp.WebAppFilterChain.doFilter (WebAppFilterChain.ja va:190) [2008-01-10 11:31:01.379] at com.caucho.server.dispatch.ServletInvocation.service (ServletInvocation.j ava:229) [2008-01-10 11:31:01.379] at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274) [2008-01-10 11:31:01.379] at com.caucho.server.port.TcpConnection.run(TcpConnection.java:511) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:520) [2008-01-10 11:31:01.379] at com.caucho.util.ThreadPool.run(ThreadPool.java:442) [2008-01-10 11:31:01.379] at java.lang.Thread.run(Thread.java: 619) The servers are configured to persist sessions across the cluster. On both servers the size of the DB file is 500M. It doesn't grow or shrink. Is this normal? I'm concerned as to what's causing the above error.
Re: [Resin-interest] Resin clustered session store
We would send valid SOAP requests but XFire was not interpretting parameters correctly. Eg. This SOAP request: soap:Envelope xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; soap:Body list deepfalse/deep /list /soap:Body /soap:Envelope would give this response: 2007-08-08 09:59:03,894 ERROR [resin-tcp-connection-*:80-14] (DefaultFaultHandler.java:35) - Fault occurred! org.codehaus.xfire.XFireRuntimeException: Invalid boolean value: at org.codehaus.xfire.aegis.AbstractMessageReader.getValueAsBoolean(Abstrac tMessageReader.java:115) at org.codehaus.xfire.aegis.type.basic.BooleanType.readObject(BooleanType.j ava:16) at org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBinding Provider.java:169) at org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding. java:206) at org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBin ding.java:51) at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.j ava:42) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:1 31) at org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.j ava:64) at org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.jav a:38) at org.codehaus.xfire.transport.http.XFireServletController.invoke(XFireSer vletController.java:304) at org.codehaus.xfire.transport.http.XFireServletController.doService(XFire ServletController.java:129) at org.codehaus.xfire.transport.http.XFireServlet.doPost(XFireServlet.java: 116) at javax.servlet.http.HttpServlet.service(HttpServlet.java:153) at javax.servlet.http.HttpServlet.service(HttpServlet.java:91) at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChai n.java:103) The only difference would be the version of Resin used. I think someone else posted a question about it to the XFire mailing list and didn't receive a response. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emil Ong Sent: 14 January 2008 17:38 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Mon, Jan 14, 2008 at 04:54:19PM -, Richard Grantham wrote: Thanks for the response Scott. We did some firewall reconfiguration with regards to connections and sessions and the issue appears to have gone away. I've not tried the 3.1 branch in a while as we found it didn't play well with XFire, but I will upgrade to 3.0.25 ASAP. Hi Richard, What problems did you run into with XFire and 3.1? We want to make sure they work well together. Thanks, Emil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 14 January 2008 16:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin clustered session store On Jan 10, 2008, at 4:19 AM, Richard Grantham wrote: Hi list, I'm using Resin Pro 3.0.23 (2 servers, load balanced/distributed sessions) and I've seen this error a few times in the log file: We've made a few fixes to the synchronization/timing of the clustered session. Some in 3.0.25, but many more in 3.1. However, I was never able to reproduce that exact error here, so if anyone runs into this on 3.1.4 or later, it would be very helpful to send a bug report on the issue with as much detail as possible. -- Scott [2008-01-10 11:31:01.379] java.io.EOFException [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$PeekInputStream.readFully (ObjectInputStream.ja va:2279) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream$BlockDataInputStream.readShort (ObjectInputStre am.java:2748) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) [2008-01-10 11:31:01.379] at java.io.ObjectInputStream.init(ObjectInputStream.java:280) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject $DistributedObjectInputStream.in it(ClusterObject.java:474) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:286) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.FileBacking.loadSelf(FileBacking.java:318) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterStore.load(ClusterStore.java:423) [2008-01-10 11:31:01.379] at com.caucho.server.cluster.ClusterObject.load(ClusterObject.java:259) [2008-01-10 11:31:01.379] at com.caucho.server.session.SessionImpl.load(SessionImpl.java:702) [2008-01-10 11:31:01.379] at
Re: [Resin-interest] ResinObjectFactory does not support scope
On Jan 13, 2008, at 8:47 AM, wesley wrote: When annotated class with @Component combined with @SessionScoped (or @ConversationScoped/@ApplicationScoped), ResinObjectFactory throws java.lang.RuntimeException: java.lang.reflect.InvocationTargetException I'm using s080111 snapshot. I've filed this as http://bugs.caucho.com/view.php?id=2332 Is the object a normal bean or is it something like a struts2 action? If it's a struts action, then it really shouldn't have a @SessionScope (?), since it's a singleton. Also, do you have a full stack trace? thanks, (BTW, we've added a wiki page for the struts2 integration at http:// wiki.caucho.com/Struts2) -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] class loader question on linux?
Thx Scott again! So I can put java code in resin lib, but... the native .so code, should that also go there? tia, .V The java classes for any JNI code should normally be at the system classloader level, e.g. in resin/ext-lib, not in WEB-INF/lib. The JDK only lets you load a native library once, which causes all kinds of problems with web-app reloading. So you want to put JNI code at the system level so it's never reloaded. -- Scott Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] snapshot (08/01/14): adding spring/webbeans and embedded resin
It sounds very interesting. On a side note, the link at the top of the page to the javadocs (ResinEmbed JavaDoc - http://caucho.com/javadoc/com/caucho/resin/package.html) returns a 404. S! D. Scott Ferguson escribió: The new snapshot should fix the build issues people have been having. The previous one had only partially updated the configure and make files. It also includes a basic integration of Spring with Resin's WebBeans. The wiki has some details at http://wiki.caucho.com/Spring. Basically, you can set Resin as a parent BeanFactory of Spring's web- app ApplicationContext. If Spring can't find a bean in its own context, it will ask Resin to see if the bean is configured in Resin. http://caucho.com/resin/doc/resin-embedding.xtp has an overview of the embedding API for Resin, which a number of people have asked for. The embedding API can be used for things like unit testing, Maven integration and IDE integration. -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- --- Daniel Lopez Janariz ([EMAIL PROTECTED]) Web Services Centre for Information and Technology Balearic Islands University (SPAIN) --- ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
