Hi there,

Now that version 4.0.0 has been released, I've tried again to integrate 
Resin into the Wembed project, which uses embedded container engines to 
facilitate automatic testing and I can happily confirm that version 
4.0.0 works fine :). Just some minor issues:

.- The default logging level is a bit verbose, as it is set at the info 
level and each line is doubled, as it is set to showing the full name of 
the class and the method from which the trace originated. Like:
22-may-2009 10:31:12 com.caucho.server.cluster.Server start
INFO: resin.conf = null
22-may-2009 10:31:12 com.caucho.server.cluster.Server start
22-may-2009 10:31:12 com.caucho.server.cluster.Server start
INFO: server     = (:)
Is there any place where I can configure, more or less easily, the 
default logging level in an embedded instance?

.- The embedded engine requires a JDK for compiling as it needs a Java 
compiler, but... is it possible to configure it to use an "embedded 
compiler" like Apache Jasper or similar so it can be packed with the 
engine? It's not a big problem, but usually the default behaviour for 
.jar files, at least in Windows, is to be run with the JRE, and that 
implies that, by default, Resin chokes whereas Jetty and Tomcat do not. 
It's "the user's fault" but in any case I would like to be able to make 
Resin easier for "the average Joe" to use.

.- Las issue is a licencing one. Resin's license is GPL, so I cannot 
pack it with the regular release, as the project is under the LGPL. But 
I could create a different package with the resin libs and with the 
single Java file that start/stops the server and is called through a 
neutral interface, and release that class under the GPL. Would that be 
ok for you, Caucho? The thing is that I want to promote Resin and I want 
to make it easy for users to test their applications with it, but I 
don't want to run into any legal trouble :). Packaging it with the 
default release would be great, Jetty and Tomcat 5.5 are already 
included, but that won't work so having an optinal package would be 
second best. I don't think getting users to download the .jar files 
themselves and putting them in the appropriate places would make it too 
popular. So, is the separate package and acceptable option for you guys?

Salute and keep up the good work! :)
Daniel Lopez Janariz (d.lo...@uib.es)
Web Services
Centre for Information and Technology
Balearic Islands University

resin-interest mailing list

Reply via email to